
Issue number 10 
July 2007 


FREE to download magazine dedicated to all Commodore Computers available FREE at the 

end of each month 
from www.commodrefree.com 


- Forwarded message - 

I regret to advise the Commodore community that Jim Butterfield has 
passed away. Jim died at 1:30 AM on June 29 after battling cancer 
which infected many parts of his body. 

His family advises that there will not be a funeral as such but a 
commemoration of Jim's life is planned in the next month or two. 

At the moment that is all the detail that I have to report. 

We have all lost a truly wonderful friend and teacher. 


Ernie Chorny 
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Editor Contents 


Very sad news this issue with the passing of Jim 
Butterfield on the 29 th of June 2007, For many Jim 
was an inspiration taking complex information and 
changing it into a format many people found easier to 
digest. I am sure he will be missed by a great many 
people. 

Jim's Work should not be lost, we should pool our 
efforts and create a website with all his works in one 
place. Other younger users may not have read or 
met Jim and should not have to go without his words 
of wisdom. 

I try to contact users and manufacturers that I would 
like to read about as a Commodore user, for example 
last month was an interview with worldlam about 
potential purchase of CMD and why he is buying up 
so much Commodore equipment. Some people felt 
the interview wasn’t justified and a waste of time. I 
disagree because it raises the question about CMD 
and the problems Maurice is having in manufacturing 
the products. Maybe Maurice should sell the 
hardware and concentrate on the software side. 

Many people feel angry to Maurice, I myself feel 
some anger that Maurice took my money knowing full 
well he could not provide the goods in the time scale 
he promised. Also Maurice won’t answer any of my 
emails, and requests for a refund of my money. 

We need good companies supporting Commodore 
but having a company take money and then have 
problems providing the goods is just having a 
negative effect on the community. 

I was ready for some hate mail from the Worldlam 
interview, although it wasn’t realy hate mail more that 
people felt there were others who should have been 
interviewed instead. 

Ok interview them and send me the questions and 
answers session, I will print the text in the magazine 
remember the Commodore Free team is just ME, and 
it’s a lot of work to produce in just 1 month, also 
remember the amount of work that goes into asking 
questions, some users agreed to interviews and I 
would write the questions but never receive answers 
for whatever reason, this is fine but it takes me more 
time, I need your input and articles 

Thanks 

Nigel 

www.commodore free.com 


Can you help 

If you are working on a project, hardware or software 
based for any of the Commodore machines please 
can you let me know, so I can include it in the 
magazine. 

Want to help but don’t know what to do and don’t 
think you could write a review, just send a link, don’t 
worry if I may have seen it or not, send the link so I 
can contact the creator for more information 

Thanks 


Editorial and contents 

Page 2 

News 

Page 3-5 

Programming The great adventure 

Page 6-8 

Interview Amiga hardware book 

Page 9-10 

Interview Codebase64 

Page 11-12 

Flex files part 5 

Page 13-14 

Potrace F.A.Q 

Page 15-16 

Interview Potrace 

Page 17-18 

Interview Slang 

Page 19-20 

Slang Quick Reference 

Page 21-22 

Slang Tutorial 

Page 23-26 

Interview PIDD64 

Page 27-28 

Interview Jim Butterfield by Jim lawless 

Page 29-31 


Commodore Free is a FREE to download magazine 
in PDF TEXT D64 image and Html normally 
produced at the end of every month 


www.commodorefree.com _ Page - 2 





Commodore Free Magazine 


NEWS 

The Internet for Commodore C64/128 Users by 
Gaelyne Gasson is now available as a PDF 
download from the Commodore Central Market, 
which now is part of our online store. We actually 
have two PDF versions available. One is an exact 
page-for page copy of the 3rd edition for those who 
want the book completely as it was written and 
formatted. The other PDF version has been edited to 
include 'PDF bookmarks' for chapters and 
subheadings, and references to other chapters have 
been made into clickable links. Also URLs that are 
still valid have also been made into links. 

TIFCU is not just for Commodore users these days. 
Several years ago we moved our servers to Linux, 
and for the first few months we found TIFCU to be 
invaluable for looking up how to do basic things on 
our system. We've heard from several other people 
who've found it useful for use with their Linux 
machines as well. 

The price is $10.00 Australian (about $8.50 US) and 
once payment is received you can download the PDF 
file immediately from the store. 

We're running a special offer on the TIFCU book and 
Flomestead Plus Membership. If you purchase a 
Flomestead Plus Membership ($35 AU or about $29 
US), you can receive the book at half price. 
Flomestead Plus is the name of our Telnet 
memberships as it better reflects the fact it’s used by 
members of the Flomestead mailing list. It’s also quite 
OK to have a membership without actually using the 
Telnet services. Some folks have done this as a way 
to donate to our cause of supporting Commodore 
computing and naturally we are pleased with all our 
Flomestead Plus Members whether they make use of 
it or not. :-) 

The special offer for TIFCU at half price also applies 
to Flomestead Plus Membership renewals paid for via 
our online store. 

We've moved the Commodore Central Market into 
the same shopping cart system that we use for other 
items we have for sale (gameboy items, phone 
covers, webcams, breath testers and other various 
items). The C= Central Market has it's own area 
which can be found at: 

http://shop.vcsweb.com/index.php7main paqe=index 

&cPath=24 

One of the features of our new online store is that 
people can write reviews of products, and we're 
looking to add more reviews to our various C= 

Central Market items. If you've purchased something 
from the market in the past and write a review of it, 
we'll give you 10% off your next purchase. Just visit 
any item in the store, click on the 'Reviews' link and 
the next page will have a link to submit your review. It 
will ask you to login or to sign up as a store member 
before you can submit your review - this will make it 
faster to place an order and allow us to give you the 
10% discount. 

Please come have a look at the new C= Central 
Market today! The link is: 

http://shop.vcsweb.com/index.php7main page=index 

&cPath=24 


High Voltage SID Collection Update #47 
Date: June 07, 2007 

Resulting Version: 47 
Previous Version: 46 

As usual, the update and the all-in-one packages are 
available from http://www.hvsc.c64.org After this 
update, the collection should contain 34,127 SID 
files! 

This update features (all approximates): 

1127 new SIDs 

19 fixed/better rips 

8 fixes of PlaySID/Sidplayl specific SIDs 

8 repeats/bad rips eliminated 

773 SID credit fixes 

700 tunes assigned a sidmodel flag 

15 UNKNOWN demo tunes identified 

29 UNKNOWN game tunes identified 

Main Composers featured in this update: 

(Artists marked with NEW are either completely new 
to the HVSC or they get their own directory in this 
update) 

# A-Man - venturing into Pollytracker domain now! 

# Bart 

# Richard Bayliss 

# Bernhard Burgstaller (NEW) 

# Chantal Goret (NEW) 

# CRD - kindly donated his complete collection to us 

# Dexter (NEW) 

# Eco 

# Fanta - listen to his Desert Dream conversion! 

# Fox 

# Gop 

# Greg 

# Gregfeel 

# Harlequin 

# Heinmuck 

# Hukka 

# Image 

# MAC2 

# Mac/Radical 

# Merman 

# Moogle Charm (NEW) 

# Nastiness Inc. 

# Omoroca (NEW) 

# Pernet 

# Q-Man 

# Raze 

# Rio 

# Sax 

# Sharp 

# Skam (NEW) 

# Slayer 

# STP Sound System 

# Tonid (NEW) 

# Topaz 

# Vintaque 

# Zeta (NEW) 


All the Very Best, 
Gaelyne & Rod Gasson 
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HVSC News 

Motion joined the HVSC Crew 

Steppe retired from the HVSC admin post. 
Rambones will take over, good luck! 

The new directory structure requires a new update 
tool. It got updated for Linux and Windows, so we 
feel the majority of users won't have a problem. 

For the exotic platform users: The source code of 
update tool 2.8.4 ison the HVSC website in the 
Downloads section. If you manage to compile it 
on your specific platform, feel free to send it over! 
And by the way: You can still run update #47 with 
update tool 2.8.3.It will complain heavily that the 
/Hubbard_Rob/ directory is not where it expects it to 
be, thus assuming you did something fundamentally 
wrong. Just ignore the warning, nod away the next 
"y/n are you sure you're sure?" question and it will 
work anyway. 


SID related news bulletin 

STIL Bonus released For all you STIL junkies out 
there curious about some of the module tunes 
mentioned in the STIL, the HVSC team now offers 
the STIL Bonus: 

http://www.prg.dtu.dk/HVSC/STIL_Bonus/ 

The STIL Bonus is a collection of MODs, XMs, 
MP3s, and other assorted tunes referenced in the 
STIL. This collection was previously available under 
a different name (MCOT 64) but on a much smaller 
scale. The collection is now 63MBs compressed, 
and offers some very memorable game and scene 
tunes from the Amiga, PC, and other sources. 

The collection was put together in order for the 
HVSC team to verify several STIL entries for 
correctness. We then thought it would be a nice 
collection that the public may also enjoy. For some 
of you, you may have never heard these tunes. For 
others, it may be a trip down nostalgia lane. You may 
even find that you actually prefer some of the SID 
versions while for other cases the modules/MP3 will 
be preferable. 

PSID64 v0.8 is out! 

The popular ,sid->.prg converter saw another update. 
New features include: 

* Built-in support for Exomizer. 

* Added support for a joystick in port two to control 
the player. 

* Added clock to indicated running time. 

* Added -i option to override the initial song to play. 

* Added support for SID tunes written in BASIC. 

Grab it here: http://psid64.sourceforge.net/ 


Ebay News 

Commodore FREE I managed to find this on ebay 

Commodore 64 Disk-Rob Hubbard and Martin 
Galway Music 

You are bidding for a Commodore 64/128 disk 
comprising of VERY RARE music demos by two of 


the leading artists from the eighties, Rob Hubbard 
and Martin Galway. 

Side A is a very very rare music collection of Rob 
Hubbards most famous tunes. You will be hard 
pressed to find this demo disk anywhere nowadays, 
very rare and highly collectable, I doubt you will find 
this on any rom collection, this demo is not even 
included on the TOSEC Commodore set which 
includes 1000's of games, demos, compilations etc. 

Simply load the disk into your drive and press keys 
A-Y, some of the tunes on this disk include: 

Crazy Comets 
Monty on the Run 
One Man and His Droid 
Thing On A Spring 
Zoids 

Bump Set Spike 
and much much more 

Side B includes a great collection of Martin Galway 
tunes from yesteryear, again this demo disk is very 
hard to come by. Again, simply load in to your 
Commodore and press keys A-0 , Some of the tunes 
include: 

Highlander 
Ccean Loaders 1-3 
Parallax 
Comic Bakery 
Hyper Sports 
Wizball 

Rambo Loader 
and much much more. 

This disk is in full 100% working order. Bid with 
confidence from a trusted eBayer! 

Keep an eye on my auctions for more of this type of 
material in the future. 

Postage will be free if purchased with buy it now! (UK 
ONLY) 

Commodore Free 

Selling price was £4.80 + 1.50 postage costs for what 
looked like a new disk with colour picture of rob and 
Martin on the Cover, but it looked like it was just 
produced, couldn’t you just download the sid files 
Free. Expect a large amount of these disks to appear 
soon. To the buyer it must have been worth it, but I 
remember years ago downloading some of these 
compilations, and somewhere I must still have 
around 10 disks with music files on, with a nice front 
end press A for XXX B for YYY etc. 

QVC 

Qvc in the Uk is a shopping channel, it featured a pc 
special with Commodore, the program started with an 
about Commodore brand (of old) and theCommodore 
64 and Amiga machines, The presenter confessed to 
owning an Amiga 

Then the presenter and Commodore Representative 
went thorough the machines specifications and 
different cases, the unit was available with monitor 
keyboard and speakers or just as a base unit, They 
have a retro design that looks like a Commodore 64, 
very neat looking case, Maybe they should sell just 
the case with no internals 
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Commodore Scene 
VGA project 
terminated 


IDE64 V4 
Prototype 


As you can see in the picture the IDE64 V4 prototype 
is ready. Although there are still some work need to 
be done before it will be finished, we would like to 
present one of the major improvement which is 
increased performance. 

The IDE64 V4 is faster by 16% than IDE64 V3.x and 
even 37% faster than RamLink while loading the 
same amount of data.We would like to thanks to all 
C64 users (who asked us about IDE64 availability) 
for the patience. We are sorry IDE64 is not available 
at the moment. 

posted by Josef at 5/21/2007 


Known as C=VGA 


www.commodorescene.orq.uk 

Alan has recently informed me he has terminating the 
Commodore VGA project. The project was to design 
a self contained unit to connect Commodore 64 and 
128 to standard VGA monitors, the unit would also 
allow the use of 80 columns and all colours on LCD 
and CRT monitors 

Alan released a statement to me 

“I didn't get anything although I did see the working 
prototype many years ago. I've closed the project on 
my web site so its common knowledge, so please 
pass on this information. BUT, I am still going to try 
this new device(s) as a matter of urgency and I am 
ordering the parts today so I would appreciate any 
mention of the C=VGA closing also mentions that I 
am actively sorting out an alternative which I hope to 
have completed by the end of July.” 

Well the meeting in Florida didn't take place and so I 
have had to make the decision to close this project. 

All money will be refunded. 

However, that is not the end of the Commodore/VGA 
story just yet. Please pop along to 
http://home.comcast.net/~kkrausnick/c128-vga/c128- 
vga.html and see what is happening there. I am 
ordering the components to make the same set up 
myself and if all is well I will post a components list 
and installation instructions up here during July 

So closes another project, Alan has said to “watch 
this space though” Alan has said will be refunded. 
Lets hope Alan can arrange another suitable 
alternative 



Performance comparison: IDE64 V4 vs. IDE64 V3.x vs. RamLink 
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Programming The Great Adventure 
of Creativity and Logic 
by Dave Moorman 


Come with us as we enter a strange world of symbolic 
logic. Process Logic, to be exact. If you do those logic 
problems found in puzzle magazines, you know Classic 
Logic. If you found Geometry enjoyable in high school, 
you know Proof Logic. And if you studied philosophic 
logic in college, you are aquainted with Symbolic Logic. 

Process Logic is a combination of Proof Logic and 
Symbolic Logic -- plus three wonderful additional 
features. Like Proof Logic, you will be arranging 
statements and commands in a particular order - not to 
prove some truth, but to affect some action in the 
computer. In the process, you will use Symbolic Logic to 
manipulate values. 

The three additional features are 

1. symbolic value holders(called variables and arrays), 

2. loops 

3. conditional commands. It is the ability to make 
conditional changes in the flow of logic that gives a 
computer its ability to "think." 

The C-64 includes a built in BASIC interpreter. 
Computers are controlled with three types of language. 
At its very heart, the computer processor recognizes 
certain values as "instructions." This is built into the 
machine itself, and is called Machine Language. 
EVERYTHING the computer does is really done by 
means of ML. 

ML is nothing but numbers, that is, numeric values. 
Remembering such values and the tasks they perform 
can be extremely difficult for humans. We need at least 
some easily recognizable code "words" to remind us 
about what is going on. The ML programmer writes 
these "words" and the computer uses a program to 
ASSEMBLE that code into ML -- which is what the 
computer actually understands. The code the 
programmer writes is called ML, or more correctly, 
Assembly Source Code. 

But a computer can be smarter than that. Assembly ML 
source code has a one-to-one relationship with the code 
the computer understands. Each instruction does one 
and only one very small task. Keeping it all straight can 
be quite frustrating. 

However, the computer can be programmed to read 
words, numbers, and other characters and translate 
them into complex groups of ML instructions. Such a 
language is called Compiled. The program that 
translates Compiler Code into ML Code is called a 
Compiler. A compiler compiles an entire program or 
routine at a time. If the programmer has made a mistake 
the compiler cannot understand, it reports errors -- but 
only after chugging through the whole source code. So 
the programmer writes, compiles, debugs, recompiles, 
executes, rewrites, recompiles, etc, etc. This is an 
arduous task, to say the least. It was even more 
frustrating back in the 1960's when the programmer had 
to punch cards with each line of the program and take 
the "batch" to the computer room. The operator would 
run the batch and return a paper print-out to the 
programmer in a few hours. Or days! 

At that time, computers (big mainframes) were finally 
becoming fairly fast and powerful. A terminal could be 
directly connected to the computer so the programmer 
did not have to wait. But the computer then did a lot of 
waiting -- for the programmer's input. The concept of 
time-sharing was developed, where the computer could 


switch between many different terminals, running 
different programs at apparently the same time. 

To take advantage of time sharing and to provide a 
language that was easy for students to learn and use, 
BASIC (standing for Beginner's All Purpose Symbolic 
Instruction Code) was written (invented) in 1963, at 
Dartmouth College, by mathematicians John George 
Kemeny and Tom Kurtzas. The commands and math the 
programmer typed looked enough like English, making 
reading the code relatively easy. 

But the big advantage of BASIC was that it was - and is 
-- an Interpreted Language. During the user's tiny slice of 
processor time, a single BASIC statement would be 
read, turned into the ML Code necessary to execute the 
command, and processed. Then the processor turned to 
another terminal and program to process. On the BASIC 
program's next turn, the next BASIC statement would be 
interpreted and executed. 

The great thing about an interpreted language like 
BASIC is that the program runs until an error occurs. 
Then it stops and delivers an error message. The 
programmer can fix the error and rerun the program. 

This made BASIC very interactive. The programmer did 
not have to get everything right before seeing how at 
least SOME of the program performed. In December of 
1974, the January issue of Popular Electronics published 
news about the first home computer -- the Altair 8800. 
Two Harvard students, Paul Allen and Bill Gates saw the 
magazine - and their future. They dropped out of college 
and rushed to Albuquerque, NM, where the Altair was 
being built. 

They realized that these home computers needed an 
"operating system" - a simple way for users to interact 
with the machine. Bill Gates wrote Altair BASIC using a 
mainframe computer with an emulator that made it act 
like the Intel 8008 microprocessor used by the Altair. His 
BASIC included ML code to read the keystrokes and put 
the BASIC program into memory. Other code would read 
BASIC commands and jump to ML routines that 
performed them. The whole thing fit in just 4 kilobytes of 
memory (which doesn't seem like much today, but was 
rather expensive at the time). 

Gates and his newly founded company - Microsoft -- 
went on to write BASIC for nearly every home computer. 
BASIC 2 used about 16K of memory, but was 
remarkably powerful. Most anything a programmer 
wanted to do could be done in BASIC. True -- it was 
slower than straight ML. But is was easy to learn, faster 
to write, and more-or-less portable between different 
makes of computers. 

When in 1978 Commodore Business Machines 
produced the Personal Electronic Transactor - the PET - 
- they turned to Microsoft for BASIC. Commodore CEO 
Jack Tramiel bought BASIC 2.0 outright for $10,000 from 
cash-strapped Microsoft. 

So, in the fall of 1981 when Commodore designed the C- 
64, they already owned the BASIC 2.0 operating system. 
The C-64 has color video and other features for which 
BASIC 2.0 had no commands. But that was OK. Game 
designers would certainly use fast ML for their code. And 
BASIC 2.0 has commands which can directly read or 
write information to places in memory that will control 
these features. 
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On the up side, the C-64 was designed to be modified 
with ML code. Though BASIC 2.0 was in Read Only 
Memory (ROM) and could not be changed, certain 
critical jump locations were in Random Access Memory 
(RAM -- which can be altered). By changing the jump 
addresses, a programmer could add new commands to 
BASIC and perform all sorts of miracles the designers 
never dreamed of. The designers did include "paddle 
controls" for then-popular games like Break Out. These 
controls proved perfect for adding a mouse. 

All in all, a C-64 was a fantastic machine in 1982 when it 
was unveiled at the January Consumer Electronics Show 
in Las Vegas. Its capabilities -- especially as a "game 
machine," and its incredible price that dropped to less 
than $200 in 1994, kept it in production through 1992. 
Over its decade of manufacture, some 27 million units 
were sold, making the C-64 the "Best Selling Computer 
of the 20th Century," according to the revered Guinness 
Book of World Records (2000-2001). 

In the late 1990's, PC programmers who loved the C-64 
began writing emulators to allow a PC to run C-64 
programs. The best of these, the Versatile Commodore 
Emulator, continued to be improved until it brings an 
almost perfect C-64 to the world of Windows. With VICE, 
all the great games published over the years on 
LOADSTAR are now at your finger tips. And to top of a 
remarkable (if often ignored) history, a C-64 Direct-to-TV 
game joystick was marked in 2004 through QVC, the 
shopping channel. Over 200,000 unites were sold 
between Thanksgiving and Christmas. 

Thanks to the designer -- Jeri Ellsworth -- the computer 
inside the joystick is a real, honest-to-goodness C-64. 
With nine wires soldered to the credit-card-sized board, 
a user can connect a PS2 keyboard, Commodore disk 
drive, and an external power supply.The Commodore 64 
- more than any other first-generation, 8-bit computer -- 
has proved itself as THE computer for gamesters and 
hobbyist programmers all over the world. 

INSIDE the C-64 

Every computer has three essential parts — 

1. A processor which executes ML instructions and does 
math and logic operations. 

2. Input/Output capabilities — for keyboard, mouse, 
joystick, printers, and disk drives. 

3. Memory - "itty-bitty boxes" called bytes which can 
each hold a value of 0 through 255. 

Today's computers can handle up to 8 bytes at a time, 
making them incredibly fast. Such speed is necessary for 
processing sound recording, photo-quality images, and 
real-time videos. 

The first generation computers (such as the C-64) had 
processors that could handle only one byte at a time. A 
byte is composed of eight bits -- little switches which are 
on or off, 1 or 0 -- hence these are called "8-bit 
computers." A two-byte value is used to point to a 
particular byte in memory, which means that an 8-bit 
computer is limited to 256 x 256 or 65536 bytes of 
memory. One kilobyte is actually 1024 bytes, so 
65536/1024 equals 64. Thus the name Commodore 64. 
But the C-64 has more than 64K of memory. The ROM 
which holds all the ML code to make BASIC wois 
"banked" on top of RAM. By "flipping" certain bits in the 
computer, an ML programmer can set ROM aside and 
use the RAM "underneath." 

As mentioned before, even though BASIC 2.0 is 
powerful, ML programmers have created a number of 
BASIC extensions and ML modules to add features for 
BASIC programmers. In 2004, LOADSTAR featured 
DotBASIC which adds 72 commands to BASIC 2.0 -- 
including full mouse control and Event Driven 
programming. Other modules play music and sound 
effects in the background, enable easy access to bitmap 


graphics, and even let ordinary BASIC programmers 
operate sprites (movable screen objects) and do split 
screen effects. 

THE LIMITATIONS 

The 6510 microprocessor in the C-64 operates at 1 
megahertz (millions of cycles per second) -- which is 
slow compared to the 8+ Gigahertz (billions of cycles per 
second) Pentiums now on the market. However, IMhz is 
still 1,000,000 clock cycles per second (not slow, really) 
and 6510 ML instructions are quite efficient compared to 
Pentium instructions. The screen is comprised of 60,000 
pixels -- 320 x 200. In multi-color mode, two bits 
determine which of four colors will be displayed as 
double-wide pixels (160 x 200). The result is a bit grainy. 

Text characters are all 8 x 8 pixels in size, and can 
display the character "cell" color or the background color. 
In multi-color text mode, double-wide pixels can present 
the character color or one of three "universal" colors. The 
font includes 256 characters, but the programmer is not 
limited to the two built-in fonts. With a font editor, one 
can design characters as any 8x8 combination of 
pixels. Moreover, the programmer has eight 24 x 21 pixel 
sprites -- movable objects -- that can be designed and 
displayed anywhere without disrupting the screen. 

The whole screen can be nudged, pixel by pixel, in any 
direction, enabling smooth scrolling effects -- especially 
when combined with split screen capabilities. 

Sound is limited to three synthesized voices. The 
synthesizer has only Attack, Decay, Sustain, and 
Release envelope parameters, but does include various 
filters and resonance settings. Waveforms include noise, 
sawtooth, triangle, and adjustable pulse. And, with some 
cleverness, 4-bit recorded sound can be recorded and 
played by the computer. 

So while the C-64 has certain limits, it is crafted in such 
a way that truly capable programmers can accomplish 
most anything computational. I have seen real-time 
three-dimensional displays (like DOOM, only very low 
resolution), the MGM Lion roar, and hundreds of other 
truly amazing sound and video effects. But most 
important, anything one can do on any computer can be 
at least MODELED on the C-64. The model may be 
rough, but the concepts, skills, and personal satisfaction 
in accomplishing effects are the same as with a big 
computer. 

The day may come when you will want to tackle C, C++, 
C#, Java, Java Script, Perl, or Visual Basic on a PC. 
EVERYTHING conceptual and logical learned on the C- 
64 will apply to any other computer or language. 

The C-64 is where one starts -- as did thousands of 
today's professional software designers. And hundreds 
of hobbyist programmers still find enough challenge to sit 
up all hours of the night hunching over their C-64s, fixing 
just one more thing! 

ON TO BASIC 2.0 

When you turn on the C-64 (or launch VICE), the screen 
displays some title information, then presents the word 
READY. 

READY? Ready for what? 

Ready for anything you want to do! Type: 

PRINT "HELLO" 

and press <RETURN>. (On VICE, the double-quotes are 
<Shift-2>, and <RETURN> is the <ENTER> key.) 

The computer immediately complies - printing to the 
screen: 

HELLO 
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Type: ? 5 + 7 * 10 

(VICE: the plus is the <=> key, the asterisk is the <]> 
key.) (Remember to press the <RETURN> which tells 
the C-64 to go ahead and do it.) 

75 

The question mark is short for PRINT. In the first 
example, you printed a STRING, a group of characters in 
order. You marked off the beginning and end of the 
string with double-quotes. 

In the second example, you printed numeric values, 
multiplied and added according to mathematic rules 
(multiply and divide are performed first, followed by 
addition and subtraction). Both of these examples are 
examples of Immediate Mode. The C-64 immediately 
responded to your commands when the <RETURN> was 
pressed. 

Now Type: 

10 ? "HELLO" 

20 ? 5 + 7 * 10 

(pressing <RETURN> at the end of each line). 

Nothing happened - at least not obviously. But inside 
the C-64 a lot has taken place. Type: 


and the lines appear again. You have written these lines 
in Program Mode. The difference between Immediate 
Mode and Program Mode is very simple — 

If a NUMBER comes first in the line, the line is put in 
Program Memory. You can look at the program with 
LIST. If a command comes first, the line is in Immediate 
Mode and processed immediately. 

To run your program, Type: 

RUN 

Wonderful! You have written your first program! 

The number you use at the beginning of a Program line 
determines where that line occurs in the program. Type: 

15 ? "WORLD" 

and LIST 

10 PRINT "HELLO" 

15 PRINT "WORLD" 

20 PRINT 5 + 7*10 

Since every program line must have a number and will 
be ordered by its number, it is a good idea to use 10's as 
you start writing your program. Then, if you want to tuck 
something in between two existing lines, you can --just 
like you just did. 

VARIABLES 

A variable is a "box" that contains something. Each 
variable has a name, comprised of one or two letters or a 
letter and a number. Longer variable names are OK 
(unless they contain a BASIC command word), but the 
computer will not "see" more than the first two 
characters. 

Let's wipe out your first program. Type: 

NEW and LIST 
It's gone. Now Type: 


50 A3 = 10 
100 ? A1$ + A2$ 

110 ? A1 + A2 * A3 
120 END 

We have two types of data -- string and numeric. So 
we have two types of variables - string and numeric. A 
string variable has a dollar sign after the one or two 
characters. A numeric variable doesn't. String variables 
cannot be part of a math formula -- but a plus sign will 
string two or more strings together. A numeric variable 
cannot be strung onto a string -- but they can be part of a 
math formula. 

The C-64 has the greatest programming interface ever 
put on an 8-bit computer. If you want to change a 
program line, all you have to do is put the line on the 
screen (with LIST), move your cursor up to it, type your 
changes onto the line, and press <RETURN>. To list one 
line, include the line number after the LIST command: 

LIST 100 

Other list possibilities include: 

LIST -100 list everything up to line 100 
LIST 100- list line 100 and everything after 
LIST 30-50 list all line from 30 to 50 

As a list is scrolling, you can slow it down by pressing 
the <CTRL> key (<TAB> for VICE), or stop it by pressing 
<STOP> (<ESC> for VICE). 

List line 100: 

100 PRINT A1$ + A2$ 

and change it to 

100 PRINT A1$ + "," + A2$ 

Press <RETURN> then RUN the program. 

Play around with this program for a while! Try all sorts 
fo things. You can print strings and numerics together on 
the same line: 

100 PRINT A1$ + ", " + A2$; A1 + A2, A3 

Use a semicolon to separate stuff you print. Use a 
comma to tab items to columns. 

Try this: 

90 T = A1 + A2 * A3 
95 ?T; 

and run the program. Or do this: 

80 A1$ = A1$ + A1$ 

85 A2$ = A2$ + A1 $ 

Try every combination of variables and print you can 
think of. It is YOUR program. And there is nothing you 
can do from the keyboard that will hurt a C-64! 

NOTHING! 

ABOUT ERRORS 

You have surely seen some errors by now. Two things 
about errors: 

1. The program stops short at any error, and 

2. The C-64 always says READY, after an error. 

List the line and try to figure out what is wrong. 
SYNTAX means that something you typed is 
incomprehensible to the stupid machine. Fix 
it! Then try again. 


10 A1 $ = HELLO [This is just the beginning! Do take time to play with all 

20 A2$ = "WORLD" the concepts presented. Only with play will you learn 

30 A1 = 5 how to apply the commands to your program.] 

40 A2 = 7 
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Interview with Mario Misic 
The big book of Amiga Hardware 

http://amigahardware.mariomisic.de/index_e.html 

Q - Please introduce yourself to our readers Q - So anyone can send information, if our reader 



Dear readers, I'm a 39 years old and I work as the 
Managing director at a Tyre shop. Since the age of about 
10 or 12 years old, i have used Commodore computers 
and have learned to love them. 


Q - What was your first experience with Computing and 
especially the Commodore 
Brand? 


My first experience with 
computers was in the Middle 
of the 80's and the first 
computer I played around 
with was a VC20 later I used 
a Commodore 64, before 
eventually using the Amiga. 
Unlike most people, I don't 
play games on these 
machines. From the start, i 
asked myself: "why has the 
Amiga (workbench)-window 
4 corners and not six, eight 
or even more?” “Why are 
they rectangle and not 
round?” “Why must I use a 
machine in a certain way,” 
“Why can't use the machine 
in a way, which I WANT?" 


Thinks he has some value to add to the project how 
Would he contribute? 


Everyone is welcome to send contributions to the 
BBoAH. Behind the BBoAFI there is a small team of 
people, who will try to verify the contributions and do the 
updates on the various items 
of hardware. We try to give a 
response to each contributor - 
if his suggestion becomes part 
of our database. But don't be 
angry, when you don’t receive 
a reply. Maintaining the 
BBoAFI is a lot of work and 
time, more time than you can 
imagine, and sometimes one 
of the contributors could be 
forgotten. 


Q - So there images of the 
products as well as text 

We like to receive as much 
information as possible for 
each item of hardware. We try 
to collect all information about 
Amiga hardware. This could 
be: Images, hardware descriptions, Jumper settings, 
install disks and much more. 


Q- What Commodore machines do you own and which 
of these are still actively used by yourself 

Within my Commodore-time, I first used the VIC20, then 
later the C64, Then moving to a C128 before I came to 
the AMIGA. All machines have fascinated me for a long 
time. I learned about an absolutely new technology and I 
was very interested and keen to learn, all about how this 
new technology worked. Now, in the 21st century, no 
other computer has reached the so called “AMIGA 
feeling.” 

Q - Please tell our reader about the Big Book of Amiga 
Hardware project, what is its main aim 

The Big Book of Amiga Hardware (BBoAH) was created 
by Ian Chapman over 8 Years ago. Over the years, Ian 
tried to find some Users, to host a mirror of the BBoAH. 
But no one had the power to keep a mirror running for 
long. A few years ago I set up a German mirror for the 
BBoAH and i was the first one to mirror the website, 
Additionally to Ian's main BBoAH I established a mirror 
and provide this "step by step" guide with an additional 
part in the German language The main aim of the 
BBoAH is, to support all interested people with 
information about every piece of hardware created for 
AMIGA computers. Without becoming a commercial 
project. 

Q - How many people contribute to the project will you 
accept information from anyone 

Over the last 9 years, hundreds of Users have 
contributed the BBoAH with different kinds of information 
about AMIGA related hardware. So many people have 
supported the BBoAH, that it's impossible to name them 
all here. Some people have sent us Images. Others sent 
us further information, documentation or special jumper 
settings, manuals, install introductions or driver disks. 
Without this support of the AMIGA community, the 
BBoAH, today, would not be the resource it is. 


Q - Was it the projects intention to provide things 
like driver disks and installation software 

The main intention of the BBoAH is, to provide the 
AMIGA Community with all information they would need. 
This will include as stated earlier driver disks, installation 
guides and manuals. Until just one year ago, you may 
remember, a lot of those files were provided by the 
BBoAH, for download, but For legal reasons, the 
download area of the BBoAH had to be closed. In the 
last year some copyright owners "attacked” the BBoAH 
and forced them to close the download area. However 
we continue to collect all related suggestions. But we 
can't name a date, when download area becomes live 
again. 

The BBoAH Team is annoyed about copyright owners, 
who actually support the AMIGA platform in NO WAY, 
but "attack" the BBoAH with legal and copyright. The 
BBoAH was and is still a hobby project and we don't 
have plenty of money to pay lawyers to defend the 
BBoAH against legal issues. The Users of the BBoAH 
have no idea, how complicated the background of the 
BBoAH is.There are a lot of complications we have to 
consider. These things we try to keep away from our 
users. 

Commodore Free - Copyright yes I understand you’re 
problems I have tread on this path myself 

Q - Do you have images of the boxes the items came 
Packaged in, is this something you would like to see 
for the project 

At the moment, we don't collect images, of boxes or 
packages. Pictures of Boxes only have an individual 
background and do not really affect the Hardware 
information and hardware use.. The BBoAH won't be a 
museum. It will be a guide for those users, who use the 
AMIGA'S day by day. 
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Q - What is documented, is it just make model serial 
Number or are there things like instructions and 
Installation guides etc 

In past the BBoAH provide the hardware support with as 
much information as was possible. But since we've 
touched by legal reasons we've come together, to come 
closer to the will of the right owners. We don’t want the 
BBoAH getting in danger and having to be closed 
because of legal reasons. 

While Ian Chapman owns the BBoaH, the english law 
was considerably. After Ian has given the BBoAh into my 
hands, German law will take affect to the BBoAH. For 
this reason i made a relationship with the geman 
publisher “Amiga-Future". Amiga-Future is a German 
Software publisher and also a German AMIGA related 
print magazine, the magazine has been running for a 
long time. My intention in this way was, that a 
professional publisher with his Knowledge could help 
with the running of the BBoAH. 

Q - How are the entries verified does someone look 
over them before they are placed on the website 

Suggestions as they arrive will be verified by a lot of 
Amiga experienced users worldwide, before they 
become an official BBoAH-Update. The actual BBoAH 
team is supported by some well known german 
hardware developers who have been in the AMIGA 
market for many years. Because of this, the BBoAH 
team has a lot of knowledge, but cannot know all things. 
To ensure that BBoAH has correct entries. People are 
welcome to amend information, So the BBoAH never will 
be complete and everybody was pleased, to Change 
incorrect information. 

Q - Is there a downloadable version of the project or 
is it just a web only, was the project intended to be 
a commercially printed book 

Ian Chapman established the BBoaH As a HTML-based 
project at first for many years until the early 2006. The 
BBoAH until this date is available as part of the "kicktart 
Archives on DVD" In 2006 the BBoAH has changed it's 
structure from a HTML based to a database provided 
site, which will provide the BBoAH with a lot of more 
features. Actually this way provides the "Sort by 
Manufacturer" or the "Sort by connection" -feature. Also 
the multilingual BBoAH become available because of 
that. At the Moment, the BBoAH is available in english 
and german language. Because of the possibilities we 
try to provide the BBoAH in other languages, too. If 
someone would like us to provide the information in 
another language please contact us, your mail is 
welcome every time. 

Q - Have you come across any problems while compiling 
the list 

Very often we get mails with new/additional information. 
To keep them all up to date just in time alone is the 
biggest "problem" we have. A massive problem in the 
near past was, to convert the known HTML based 
BBoAH into a MySQL based structure. Ian Chapman 
solved this problems by himself, and most users would 
not have noticed, that the BBoAH "structure behind was 
changed". 

Q - Is there any hardware you particularly want to know 
the details of 

We've a lot of hardware we don't know anything about. 
For this reason, we've crated a category called "Mystery 
Corner" in which we introduce unknown hardware to 
collect information, until the mystery’s solved by the 
community. In past, all our "Mysteries" have been solved 
by some of our readers. 

Q - what do you think personally of the current state 
of Amiga, are things finally starting to look up again 


for the machine 

The current AMIGA state is quite complicated. 

It's not possible to say where the AMIGA will go in future. 
I have a dream that the AMIGA would again reach the 
status, that it had in the past. But I’m old enough to let 
this dream be a dream. Today, is another time and the 
technical side is another matter all together time moves 
on and a machine from The early 80's would need 
updating, for the AMIGA to have a real chance of a 
comeback. 

Q - What in your personal view is an amiga, for 
example is it just the software (operating system) 

In my mind, the AMIGA is NOT hardware and NOT 
software. AMIGA is more a feeling, which is much more 
hard to explain like the feeling of LOVE. Amiga was and 
is a feeling you have to live to experience. The Amiga is, 
for those people, who are in my generation, a machine 
which came out at the right time in the right place. 

Q - when will the project finish, will this project run 
indefinitely, and how will you know when all hardware is 
documented 

I don't think that the BBoAH ever will be finished. 

There is so much very old hardware, which is not listed 
in our database, because no one has any information 
about this item. From time to time we get new info about 
interesting old hardware AND complete the database 
with the new info. 

Also the AMIGA community worldwide develops more 
new and interesting hardware. These items are also 
listed in the database we need more information for 
them. For example I’d like to name the A500-Clockport- 
card for example. The idea for this item was born in a 
german Amiga community. It takes a lot of months to 
discuss this item and the users wrote down their wishes 
for the device. Also a lot of german AMIGA hardware 
developers are users of this forum. At last, one of the 
hardware developers produced the hardware for the 
community. As you can see, you can see no end of the 
BBoAH. 

Q - What question would you have liked me to ask 

As a german, I've heard nothing about your great 
magazine. I feel this is harming the community; we need 
to establish much more communication between AMIGA 
and Commodore users all over the world. Especially: I 
would like to ask what is the thinking of your British 
readers about the "German krauts"? Is this a justified 
prejudice? 

That’s a really silly question, i know. But it was a 
question I'm very interested in, because we German 
AMIGA'ns have fewer contacts with British AMIGA users 
than we would like to have. 

Q - If you were given 1 million GBP pounds what would 
you spend the money on 

If i have 1 million GBP, i'd like to spend them in the same 
way as i'll spend the money, which Ian has collected with 
BBoAH donations as I announced some month ago. If 
anyone had an absolutely new idea for any amiga 
related hardware, the BBoAH would like to be involved in 
the project, helping the idea. If the most of the People 
prefer that idea, the collected money will be transferred 
to this project. 

Thank you very much for this interview and I wish you 
many success for your magazine in the future. 

Kindest regards, 

Mario Misic 

http://amigahardware.mariomisic.de/index_e.html 
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Interview with Frantic 
Codebase 64 

http://codebase.c64.org/ 


Q - Please introduce yourself to our readers 

In the c64 demo scene I am known as (not necessarily 
well known) Frantic. Member of a demo group called 
Hack'n Trade and sole organiser of the C64 parties 
known as LCP (Little Computer People) from 1998 to 
2005, and then together with other people, organiser of 
BFP (Big Floppy People) last year, and also this 
summer, in July. I live in southern Sweden in a city 
called Lund. I spend my days as a PhD student in 
Linguistics /cognition /interaction (working with gestures 
and such things), being with my wife and kid, and coding 
C64. 

Q - What is your first experience of Commodore 

I've had a C64 since I was a kid. I think I bought it 1987. 
Playing lots of turbotape games and so on. Later on I 
bought an Amiga 500 when that was hot and fresh, and 
it was first on the A500 I started creating my own things, 
like music and some simpler code. 

Q - Flow did you learn to program 

I didn't start coding "seriously" until later on when I 
moved from A500 to PC, and eventually got quite bored 
with the sterile feel of the PC computers. That's when I 
kind of turned back to the computers of my childhood 
with a new take on them. This time around I din't play 
games on them but rather all the other things that I never 
did back then and never really understood how to do 
until I got a little older. 

Q - what advice would you give would be programmers 

Take your time to think about what you are interested in 
REALLY. For example.. If you think about coding some 
RPG game for the C64. Are you just longing for that 
perfect RPG that no one else never did, or are you 
actually longing for travelling the road that leads to this 
game? That is, the actual coding part of it. If the answer 
is no to that, I think you better stay away from coding. 
Although you get a kick out of finished products of 
course I think the main drive behind coding necessarily 
needs to be fondness of the activity of sitting by your 
computer and just code. 

The same thing applies to the process of becoming a 
coder. Again you can't just long for the "finished 
product", that is, being a skilled coder. You have to like 
the road leading there too. Beginning with simpler things 
and moving one step at a time. Reading some docs, 
some tutorial, trying out some assembler, and so on. 

Q - From various users feedback, it seems actually 
getting the time to sit down and read about coding is 
difficult with real world (jobs, children etc) can 
you comment 

Well, in one sense I don't this has much to do with me or 
with C64 coding per se, but of course people have "real 
lives" to. But you gotta decide what you want to do in life. 
Do you want to spend time coding c64 or not? Or do you 
rather focus on something else? (Little of everything = 
nothing done at all.) If you want to do that, it's up to you 
to make it happen by prioritizing and so on, and you can't 
blame the wife/work/kid for that. 

Q - Do you still own any commodore machines 


Yes.. 6-7 C64 (among them the original machine I got as 
a kid), my old A500 and a A2000. I also had an example 
of that rare C65 machine, but sold it since I rather 
needed the money than a rare machine. I am satisfied 
with the common ones... C64 primarily. 

Q - Please tell us about the website and project "C64 
Codebase" what do you hope to achive 

The codebase is a wiki (a site users edit themselves, like 
Wikipedia) on the topic of C64 coding. I think a place like 
this has been lacking before, and thus I decided to set it 
up when a discussion on the CSDb forum made it clear 
for me that a lot of other C64 coders also thought that 
was a good idea and actually felt inspired to add content 
to such a site. ...which they did too. I am quite satisfied 
to see that so many different people actually involved 
themselves to add some coding routines/articles already. 

Of course there is the website called the The Fridge, 
which is very nice and a bit similar to the codebase wiki. 
There is also some forums and various coding articles 
spread all over in C= magazines and so on. All these 
forms of information structures have their pros and cons, 
but I think a wiki have some possibilities lacking before. 
For example it is a better way to store focused 
information, compared to forums which are nice and very 
useful but tend to spread information all over different 
threads/posts and interleave the relevant information 
with a lot of small talk. The wiki concept is also a bit 
more flexible than "static" magazine articles which are 
not improved upon after being published in case 
someone finds errors in it. Wikis got all this. Focused 
information spots, but still the dynamics of forums and 
other editable media. Also, the overall information 
structure on a wiki is editable, which makes it possible to 
make sure that it won't just grow into a mass of 
information where it is impossible to find what you look 
for. I do not have a clear goal with the site other than 
trying to keep it in shape. The content is supposed to 
come from all of us, rather than just from me. (Even 
though I of course encourage people to add things every 
now and then.) I will probably put up a forum there, so 
discussing specific articles/sources become possible. I 
think that is needed. It will not be a general coding forum 
though. I think the coding forum on CSDb is more 
suitable for that. 

Q - Flow many people are working on the project 

Just me, concerning the site itself. Flowever, I guess 
something like 15 people have contributed contents so 
far. Also thanks to Icon for the web server hosting and to 
Slaygon for the URL. 

Q - Is this similar to "the secret society of commodore 
coders website" 

I guess there is some similarities, but obviously one of 
them is a forum and the other one is a wiki. Forums are 
needed too of course. 

Q - Will this website teach people how to code 

It will do whatever people make it do. So far there is no 
coding tutorial there from step A to Z, but on the other 
hand there is a good collection of selected links on the 
external links section that may prove valuable for 
beginners. As the wiki grows I think everyone will 
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find something of value there, beginner or expert... 

Q - Is the website purely assembler and machine 
coderoutines or are Basic programmers welcome Basic 

programmers are welcome too, even though I guess 
most serious programming on the C64 is actually done in 
machine code for obvious reasons. 

Q - Do you think there is really a need for people to 
Learn Basic anymore 

Not really. 

Q - Some sample routines are available on the website 
are these copyrighted or can anyone use them 

The contents of the site may be used in your own 
productions. People wouldn't add the contents there if it 
was secret or non-useable for others. The wiki concept is 
all about sharing. 

Q - the items on the website have they been contributed 
by the authors or did you contact them or they contacted 
you 

The wiki concept builds on users contributing material 
themselves, and that is what they have done. However, 
in some cases I have asked people for stuff, and in some 
cases I helped a little with the process of adding the 
material. 

Q - Who can contribute, lets say our reader has 
something how would they contribute to the project 

Everyone who feels they have something C64 coding 
related that at least one other person in the world may 
find interesting is very welcome to add it. I don’t see it as 
a huge problem if people start adding a lot of contents 
not interesting for the broad masses. That is better 
handled by having a good structure on the site, than not 
adding the stuff at all. With a good structure it is easy to 
find what is there and to find what you look for anyway. 
So, don't hesitat. Go there and contribute! It may really 
be anything from small snippets to complete programs or 
articles about this and that. 

Q -1 notice most of the example are turbo assembler, 
is there a preferred assembler 

Historically it is the most used assembler on the C64, but 
in these days more and more people use PC cross 
assemblers of course. This has had the effect that most 
turbo assembler sources work with minimal modifications 
in other assemblers, as a kind of prototypical middle 
point of asm syntax. (ACME use a ! instead of . as the 
beginning marker of directives such as .byte and .word, 
and KickAssembler uses // for comments instead of ; and 
so on. So the syntactic distance between ACME and 
KickAssembler is larger than the syntactic distance 
between Turbo Assembler and these two.) However, 
apart from that, I think that actually quite a bunch of the 
sources on the site ARE written in other assemblers like 
ACME, CA65, KickAssembler and others, so I am not 
sure I agree with you. 

Q - What subjects are covered in the coding is the 
site designed for anything c64 related 

Yes, for example it is not only intended to cover demo 
coding. Tools, games and other things are also 
welcome. But, as said before, the contents depend a lot 
on what people contribute, so it is open ended in 
that sense. 

Q - Do you follow the Commodore demo scene 

Yep I do, and as I said before I am the organizer of the 
previous LCP parties and one of the organizers of BFP, 
so I guess I am quite involved in the demo scene. 


Q - Some coders want to hide there code only giving 
out various demos why share code with others? 

I can understand this. It is part of the competitive aspect 
of the demoscene I guess, which is kinda fun. However, I 
think the kind of tricks and code that you find on 
codebase is more of the kind that is in the frontline of the 
VIC trickery, and thus most people wouldn't feel like it 
was "giving away" something secret to add this stuff 
there. 

Q - From looking at some of the recent Commodore 
demos like the crest "krestage 3" it appears there is still 
a lot to learn about the machine would you like to 
comment 

Yes, I guess there will always be more to do/find out. 
However, at the same time I think that most of the new 
tricks uncovered tend to be less useful for general 
purposes than tricks discovered longer ago. For 
example, opening the borders are a lot more useful than 
adding two extra grey pixels to a sprite as in Krestage 3, 
even though its a nice hack. 

Q - Will Codebase 64 look into some of the various 
VICbugs, that are used in new demos 

Once again.. It is up to the users what information that 
will end up on the wiki. In case people are interested in it 
and want to share/discuss it, I guess it will appear there. 

Q - Do you think anyone can write computer code, 

Most should be able to learn at least a bit. 

Q - So what next for the website more code snippets 
and hints or are other changes due to happen 

Hopefully the contents of the site will continue to grow in 
the same speed as it did until now, and I'll add a forum 
there too, so people can discuss specific articles/sources 
there. Ask questions or discuss them in general. 

Q - Some reader may be put of by websites that are 
best viewed with this and that browser can you 
commenton codebase website design 

Basically it is just the default look of the DokuWiki 
engine, slightly modified colorwise and a logo was 
added. It should work good in all mozilla browsers and 
also in internet explorer, and I guess that covers 99% of 
the internet users. Although the wiki has some layers 
and such things it is mostly text based contentwise, so I 
think it should look the same in all browsers as it for all 
practical purposes. 

Q - final 2 questions, if you were given an unlimited 
amount of time and money what would you create, this 
can be none computer related 

I think I would just take it quite easy. :) Continue doing 
roughly what I do, but in a improved way. ;) But I dunno. 
It's hard to say really. I guess a lot of ideas would pop up 
if things were as you say. Maybe I would save the world! 

Q - If you won 1 million Uk pounds what would you 
spend the money on and why 

I would not buy a lot of things. I would start working half 
time and such things instead. That is quality for me. I 
already got most of what I need I think.A dishwasher 
would be nice. I don't have that. ;) 

Q - Have you any comments you would like to add 

Thanks to everyone who contributed to the codebase so 
far, and to the rest of the world, go there you too and add 
what you've got lying around hidden on your harddrives 
so that others can benefit from it. 
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HEX files Part 5 

By Jason Kelk 

www.Oldschool-Gaming.com 


Righto, time for some more code writing 
entertainment! Now, where were we? 

Ah yes, the challenge from the previous instalment; 
your mission, if you decided to accept it was to 
change the text colour to light blue and the sprite 
colour to dark blue. The text colour is altered by 
changing the LDA #$0F on line 25 of the source to 
LDA #$0E or indeed any colour you want. To change 
the sprites look at line 62. It reads LDA #$0C and to 
make them purple use LDA #$04. All sorted now? 
Good, lets get back to dissecting the remaining code, 
starting from line 71; 

main Ida #$fc 

rashold cmp$d012 

bne rashold 

Now our friend the raster has been introduced to us a 
couple of installments back, and the principle 
remains the same; the C64 projects the screen to the 
TV a line at a time and this loop waits for line $FC, 
which is just off the bottom of the standard screen. 
From here onwards the term "frame" will denote one 
complete scan of the screen by the raster, so one 
frame is a 50th of a second. 

Idx scrlcount 
inx 

stx scrlcount 
cpx #$08 
bne dontmove 

Right, we've already discussed using labels as 
places to keep numbers, scrlcount is our smooth 
scroll counter, it's counting how many frames have 
passed up to a maximum of eight to delay our 
scroller since moving it every frame would be far too 
fast to read. It's also used to work out what value 
should be in $D016 later on, but I'll explain that when 
we get there. 

Idx #$00 

scrlmove Ida$05e1,x 

sta $05e0,x 
inx 

cpx #$27 
bne scrlmove 
Idx messcount 
Ida scrolltext.x 
sta $0607 
inx 

stx messcount 

Well, this section has covered before too and it's 
basically the same scroll shifting routine we had 
moving so quickly previously. This time, however, we 
are reading from our own message in the computers 
memory at wherever the label scrolltext is. That gets 
defined later, don't worry. 

Idx #$00 
stx scrlcount 

Because we've just finished a "move" of the scroller 
we now have to reset our counter so that the 
machine will wait another eight frames before doing it 
again. Okay, now earlier we branched to dontmove if 


we were not going to move the scroll, so lets see 
where that leads us. 

dontmove txa 

eor #$07 
sta $d016 


Okay, this is just a little bit of trickery to set the 
smooth scrolling up for our message. TXA we have 
already covered, but EOR is new. EOR (or Exclusive 
OR) is what is known as a logic gate. There are three 
regularly used gates, ORA (known as just an OR 
gate, but called ORA because all 6510 commands 
are three letters long, so we add an A for 
accumulator), EOR and AND. ORA works like this: 

LDA #$64 

or in binary %01100100 
ORA #$C7 

or in binary %11000111 

Leaves A as #$E7 
or in binary %11100111 

Why? Well, look at the first column of binary 
numbers. The first two are a 0 in the top row and a 1 
in the second and the "rule" is that if either the first 
OR the second number (or indeed both) is a 1 the 
answer, in the third number in the column will also be 
1. If both numbers are a 0 the answer will be a 0, just 
like the fourth and fifth columns. 

AND works on a similar principle, except that the first 
number AND the second number must be a 1 for the 
outcome to be a 1, otherwise the answer is 0. If only 
one of the numbers is a 1 then the answer is a 0, 
meaning that if the ORA above is replaced with an 
AND the binary answer will be %01000100. 

Now for our little friend EOR. The result of our above 
example after using EOR instead of ORA would be 
%10100011 because EOR works by a different 
means. Again, it compares the columns separately, 
but if the second number is a 1 it takes the first 
number and toggles it, changes it from a 0 to a 1 or 
vice versa. If the content of the second number is a 0 
nothing changes, and the content of the first passes 
straight through. So the result of EOR #$07 on our 
counter, which runs from $00 to $07 is to basically 
invert it so that it goes from $07 to $00 and we can 
then put this into $D016 for the smooth scrolling. 

Okay, so now we've sorted out the scrolling and the 
smooth scroll, it's time for the sprite positions. 

Idx #$00 
Idy sineposx 

setsprx Ida sine_curve,y 

sta $d000,x 
tya 
clc 

adc #$20 
tay 
inx 
inx 

cpx #$10 
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bne setsprx 

Right, this is a fairly normal copy loop (as we've done 
before) but with an unusual twist. Before I explain 
how it works, I'll just quickly explain sine and cosine 
curves a bit more, which are used when demo 
programmers want to make things swing back and 
forth. At $0E00 and $0F00 are two tables of data, 
each 256 ($100) bytes long. If you were to examine 
the data you'd find that it contains the co-ordinates 
for a sprite, starting from the right hand side of the 
area it covers, accelerating towards the middle and 
decelerating at the left hand side of the area, then 
moving back in the same way. 

The above loop reads the curve at $0E00 using the Y 
(which contains another counter) and puts it into 
$D000. It then adds a value of $20 to the Y, 
increments X twice (so that it only writes to the sprite 
X values, $D000, $D002 and so on) and then, if it 
hasn't reached $10 and therefore done all eight 
sprites goes back. 

Why do we add $20? Well, it's to make all six sprites 
read from different points on the curve to produce 
that swirling effect. Try changing that value to $00 
and they all appear with the same X position. 

Idx #$00 
Idy sineposy 

setspry Ida sine_curve_2,y 

sta $d001,x 
tya 
clc 

adc #$1c 
tay 
inx 
inx 

cpx #$10 
bne setspry 


This is basically the same loop as we've just looked 
at, except that we are using sineposy, reading from 
$0F00 (the vertical sine table, slightly different to the 
horizontal one) and writing the values to $D001, 
$D003 and so forth for the vertical sprite positions. 
The ADC #$1C is different to the previous loop 
merely to make the curves a bit more interesting. It 
can quite happily be $20 or indeed any other value, 
so why not try playing with it and its fellow to see 
what you can do? 


Ida sineposx 
sec 

sbc #$03 
sta sineposx 

Ida sineposy 
sec 

sbc #$02 
sta sineposy 

Okay, this just moves the counters around for the 
sprite movement. Again, the $03 and $02 can be 
altered to change how fast the sprites swing around, 
a value of $00 will cause them to stop dead and a 
value of $FF will make them go backwards on one 
axis slowly. 


jsr $1003 
jmp main 

As explained last issue we are using an external 
music routine. Every frame we have to call the 


routine to keep the music playing and here's the JSR 
call for the tune we're using. And the JMP completes 
our loop, as we go back to main and wait for raster 
position $FC on the next frame. 

* = $2000 

message .scrl "welcome to the scrolling 

message! " 

.scrl "this little demo-ette was 

coded for " 


And to finish off this block of code, here's the 
previously mentioned label message and another 
new assembler directive to go with it. The .scrl 
command simply writes the text in quotes to the 
memory (at $2000, as specified by the * command 
above) in a format our routine can use, the letter A is 
represented as $01, B is $02 and so on. The text 
included in the source (of which only a part is 
reproduced here) is exactly 256 bytes long because 
the scroll routine can't handle any more or indeed 
less. 

Right, all done and this time I don't have a challenge 
for you, just some "play" suggestions. The values in 
the two sprite setup loops ($20 and $1C) and the 
mover ($03 and $02) can be altered. 

Why not try putting different values in and seeing 
what happens to the sprites. Some interesting ones 
to try are replacing $20 with $82, which causes each 
sprite in turn to read its position from opposite ends 
of the curve, or replacing $03 and $02 with $04 and 
$05. Go on, have a play with the numbers and I'll see 
you next time with something new to look at! As 
always, email me if you have any queries, comments 
or suggestions. 

The source code for the routines above (they're the 
same as Flex Files 4) can be downloaded here 

www.Oldschool- 

Gaminq.com/files/c64/hex files/part 6 files.zip 

© Jason Kelk 

RE-printed with the permission of the copyright 
holder 

www.Oldschool-Gaming.com 
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“Potrace” Open source tracing application 
Frequently Asked Questions 


My first name for this program was "pbm2eps", which 
was very lame and also inaccurate, because both the 
input and output file format might evolve over time. 

So I started looking for a cooler name. 

Since this program does tracing, I wanted a name 
with the word "trace'' in it. I did a Google seach for 
each combination "atrace"..."ztrace" of a single letter 
plus "trace". Believe it or check for yourself: every 
single one of them was already taken by some other 
software! 

Most of them were something boring, like the name 
of a function in some obscure statistics package 
written in Fortran. If I remember correctly, the only 
exception was "ytrace", which brought up a foreign 
language porn site called "sexo con perros". 

I am not sure what "ytrace" might mean in some 
foreign language, but I have a pretty good idea what 
"sexo con perros" means, and so I didn't want to take 
any risks giving this name to my program. 

So I started looking for 2-letter combinations. It so 
happens that "potrace" didn't yield any hits on 
Google, except a few sites that had misspelled the 
word "podrace" (as in pod-racing) from Star Wars 
Episode I. 

This was okay, I thought, and would not attract any 
trademark infringement suits. So I settled for the 
name Potrace. I particularly like this name because it 
can also mean "polygon-based tracer", which actually 
describes quite accurately what Potrace does. 

By the way, it is pronounced "po-trace", not "pot¬ 
race". If it conjurs up mental images of people 
running around a track with cooking pots, then you 
are not pronouncing it correctly. 

Question: Is there a mailing list? How can I be 
notified of new releases? 

Answer: There is currently no Potrace mailing list. 
However, Potrace has a project page at 
Sourceforge.net. This page provides a discussion 
forum, as well as a mechanism for reporting bugs. To 
be automatically notified of new Potrace releases, go 
to the Potrace project page on Sourceforge.net, find 
the section on "Latest File Releases" and click on the 
little envelope icon under "Notes/Monitor". 

Basic usage and errors 

Question: Can you show me the options used to 
generate the examples pictures on the Potrace 
website? I tried to do it myself, but failed. 

Answer: All the examples were generated with the 
default settings. The EPS files were generated by the 
following command: 

cat file.pbm | potrace > file.eps 

but the following also works: 
potrace file.pbm 


The input to Potrace in each of these examples was 
a PBM file. But since most browsers can't display 
PBM, I posted the images in PNG format on the 
website, and I also scaled them. You need to shift- 
click on the left-hand side image to download each 
original PBM file. 

The greymaps were generated by this command: 
cat file.pbm | potrace -gx2 

This generates a PGM file. Again, for posting on the 
web, I have further translated this to the PNG format 
by piping the output through pnmtopng. 

For experts only: If you want to know exactly how I 
processed these files, you can look at the Makefile 
that I used. 

Question: I installed and ran Potrace, and it did not 
work. I got the error message: sh: line 1: compress: 
command not found. What am I doing wrong? 

Answer: This error occurs only with Potrace version 
1.3 or earlier. When this happens, you should either 
install the newest version of Potrace, or else run your 
existing version with the -c option, and everything 
should work fine. 

Question: How can I improve the quality of the output 
of Potrace? 

Answer: The most effective way to do so is to 
improve the quality of the input! This seems obvious, 
but not everybody thinks of this. Scan your image at 
a higher resolution. Scan your image in greyscale, 
and use a program such as mkbitmap to generate a 
high-resolution bitmap to trace. 

In some cases, it also helps to decrease the 
resolution of the input image. If the resolution of your 
input file is incredibly high, the output generated by 
Potrace might be larger than necessary. This also 
sometimes happens if the input is speckly or noisy. 
Rather than trying to simplify the vector image, it 
often helps to just downscale the input bitmap. 

Question: How can I reduce the number of nodes in 
the output of Potrace? 

Answer: Potrace already makes an attempt to reduce 
the number of nodes, and this behavior is controlled 
by the -opttolerance parameter (or can be turned off 
entirely with -longcurve). However, I have decided 
not to sacrifice quality for quantity, and Potrace will 
not reduce the number of nodes beyond what it 
considers tolerable. 

For many applications, the problem of reducing 
output file size can be solved by reducing the 
resolution of the input image. This sounds too simple 
to be true, but can give surprisingly good results. One 
of the most common "beginner's mistakes" when 
using Potrace is to start with an image that contains 
too much detail or noise. Blurring the input image can 
also help, particularly with grey-scale images. 


3. File formats 
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Question: Why can Potrace not read/write PNG 
files? It is such a popular file format. 

Answer: In keeping with the old unix philosophy 
"write programs that do only one thing and do it well", 
I am trying to avoid writing a front end for every 
possible graphics file format known to mankind. 
Instead, I provide support for a small number of 
generic formats which are easy to convert to and 
from. 

The PNG format is relatively complex to implement, 
and there already exist many excellent programs for 
converting between PNG and the PNM format which 
Potrace can read. See the next question. 

Question: What programs can read/write PBM files 
on Linux? Gimp does not seem to help me... How 
can I convert PNG to the formats that Potrace can 
read? 


Answer: Gimp, unfortunately, cannot write PBM files 
(although it can read them). However, Gimp can write 
PNM files, as well as BMP files. Both file formats are 
understood by Potrace version 1.1 or later. Note that 
the files have to be bitmaps, i.e., they should only 
use two colors black and white. All other colors or 
grey values will be converted to black and white 
before Potrace begins its processing. 

A good program for converting anything to PBM is 
the convert command line utility of ImageMagick. It is 
invoked simply as "convert inputfile outputfile". It is 
pre-installed on many systems, and can otherwise be 
obtained from www.imagemagick.org. The output 
format is determined by the filename extension, so 
for converting to pbm, you simply type: 

convert image.png image.pbm 

Another very useful such set of command line utilities 
for converting different image formats are the 
"netpbm" utilities, see netpbm.sourceforge.net. 

Again, these tools are preinstalled on many popular 
systems. They allow you to convert between file 
formats on the command line. Particularly useful are 
pngtopnm and pnmtopng, but you can also convert to 
and from other formats using e.g. giftopnm, 
anytopnm and so forth. You can use these 
commands in a pipeline, for instance 

cat file.png | pngtopnm | potrace > file.eps 

Question: I am working to add Potrace support to 
another program, but the output of Potrace leaves 
me a little stumped. How can I parse the output of 
Potrace into some format which my program can 
use? 

Answer: To get parseable output from Potrace, I 
suggest using the -q and -c options. The default 
output is optimized for size, not readability. With 
'potrace -qc', you should get exactly what you need. 

If you use the output from Potrace for processing by 
another program, I also recommend increasing the 
output resolution, e.g., -u=100 or -u=1000, to reduce 
the effect of roundoff errors. Note that the output 
coordinates correspond to input (bitmap) coordinates, 
multiplied by the unit length, then rounded to 
integers. 

4. Color 
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Question: Can Potrace handle color images? 

Answer: The short answer is "no". Potrace can only 
handle 2-valued images at the moment. It does not 
matter whether the two colors are called "black" and 
"white" or "on" and "off" - however, there can be only 
two of them. 

Question: Will color support be added to Potrace in 
the future? 

Answer: Maybe. 

Question: How can I work around the lack of color 
support? 

Answer: There are many ways in which Potrace can 
be useful in processing color images, with some 
extra work. For example, you can trace an image to 
SVG format using the -svg and -opaque options, 
and then use e.g. Sodipodi or Inkscape to color it 
manually. 

Or you can extract individual color components from 
your image using the Gimp or ppmcolormask (part of 
the netpbm package), trace them separately, and 
then overlay the pieces to get a multicolored image. 
You can get pretty good results for posterized 
images. I have used a command line similar to this: 

cat img.gif | giftopnm | ppmcolormask #641 bl b | 
potrace 

Recent versions of Inkscape have a built-in Potrace 
engine that can handle color images via color 
quantization or multiple scanning, thanks to the great 
work of Bob Jamison and the Inkscape team. 

Another interesting application of Potrace to color 
images is described in the fascinating article 
Automatic Generation of Stained Glass from 
Scanned Photos by C. Scott Ananian. 

Graphical user interface 

Question: I don't like command line utilities. Is there 
a graphical user interface for Potrace? 

Answer: Yes, there are now several graphical user 
interfaces (GUI's) for Potrace, contributed by various 
other people. There are GUI's for Linux and for Mac 
OSX. I have not tried them myself, so I cannot say if 
they work or if they have all the features you want. I 
suggest to try them out. Please look under GUI's and 
related software on the main Potrace web site. 
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Interview with Peter Selinger 
Potrace creator 


http://potrace.sourceforqe.net 


Q - can you please introduce yourself to our reader 

My name is Peter Selinger. I am a professor of 
mathematics at Dalhousie University in Halifax, 
Canada. I develop open-source software in my free 
time. 

Q - How did you get involved with Commodore 
machines and do you still actively use Commodore 
machines 

My brother had a C-64 when I was 12 or 13 years 
old. I spent the next few years programming it in 
Basic and assembler. It was the first and 
only Commodore machine I ever used. 

Q - Can you tell our reader about Potrace, what it 
does and how it differs from similar applications? 

Potrace is a utility for raster-to-vector conversion. 

This means, it inputs a bitmapped black-and-white 
image, such as you would get from a scanner or 
digital camera, and turns it into a scalable vector 
image using Bezier curves. The output can be further 
processed with a vector graphics editor such as 
Inkscape. 

There is other software with similar functionality. 

Most of it is commercial. In my opinion, none of it 
gives output as nice looking as Potrace's. 

Q - What machines and operating systems does the 
application run on 

Potrace was written with portability in mind, so it can 
run on virtually any system that has a C compiler and 
some POSIX-like library functions. It was developed 
on Linux, and runs on every flavour of Unix, 

Windows, and the Macintosh. 

Alfred Faust ported it to the Amiga (OS4) and 
Matthias Rustler to AROS, the Amiga Research 
Operating System (which runs on Intel hardware). 

Q - Any possibility of a GEOS or Wheels version for 
Commodore 64 owners 

The source code is available; with a C compiler and 
some patience, I don't see why someone could not 
compile it for the Commodore 64. Of course, some 
expanded RAM will be necessary, as the Potrace 
source code runs to about 260 kilobytes, not 
including shared libraries. 

Q -1 notice the software is Command line only but 
other users have added GUI versions, was your 
intention to produce just a Command line version 

Yes. Potrace adheres to the old Unix philosophy of 
"doing only one thing, and doing it well". This is why I 
call it a "utility" and not an "application". It has no 
fancy user interface or add-on functionality. It can be 
used in batch mode or scripts. Potrace also can only 
read a handful of image formats. There are other, 
much better programs for converting one image 
format to another. 


Q - Can you tell our reader who contributed to the 
project and what they did 

Potrace was almost entirely written by myself. Tor 
Andersson wrote a backend for outputting PDF. Karol 
Krenski contributed the logo, which he of course 
created using Potrace. Many people have helped 
with finding and reporting bugs. 

Q - Our reader may not be aware of the "GNU 
General Public License". Can you explain this does it 
mean the software is free to use. 



For a full explanation of the license, read the file 
COPYING that is distributed with Potrace. The short 
answer is: yes, under the GNU General Public 
License (GPL), you are free to use the software. 

However, much more is true: you are also free to 
modify, recompile, and redistribute it. The primary 
restriction is that when you redistribute (modified or 
unmodified) versions of Potrace, you must again do 
so under the terms of the GPL. This means that 
nobody can integrate Potrace, or anything derived 
from it, into a non-GPL program without my 
permission. 

Please note that "free" in this context refers to 
freedom, not to price. There is lots of software that is 
offered without payment, but that does not give you 
any freedom. GPL software is not like that. 

Q - What other software have you written, and are 
you working on any other projects at the moment 

I have written lots of software. The most popular 
items besides Potrace are: 

- Ccrypt, a simple and secure command-line 
encryption program (ccrypt.sourceforge.net), 

- Upprint, a printer frontend for n-up and double sided 
printing. N-up printing means putting multiple pages 
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on a single sheet of paper at reduced size. Most off- 
the-shelf software does this very badly, by leaving 
huge margins and making the text way too small. 

Q -1 like the Potrace mascot can you tell our reader a 
little about it. 

The mascot was designed by Karol Krenski, a Polish 
artist who was an early and enthusiastic user of 
Potrace. You can see some more of his works at 

www.sqsp.edu.pl/inne/qalerie/krenski/krenski.php 

Q - what problems did you have creating the 
software, was all the code created by yourself or did 
you manage to find something similar and adapt it to 
your needs 

The largest challenge in writing this software was 
designing the Potrace tracing algorithm. This is really 
the heart of the software. I wrote all of it myself, 
except for the PDF backend. 

Q -1 see this is a FAQ already but for our reader who 
desnt read the FAQ's - Can Potrace scan and 
convert Colour files as well as mono images, are 
there plans for the software to convert colour images 

No, it cannot convert colour images. Perhaps I will 
add this ability in the future, but I do not currently 
have a concrete plan to do so. There is some 
software, such as Inkscape (www.inkscape.org), 
which is able to use Potrace on color images, 
essentially by decomposing the image into a series of 
bitonal images, tracing each of them separately, and 
then putting the results together again. 

Q - Does the software work equally well on text or 
complex images 

The best results are obtained on handwriting and 
hand-drawn images such as cartoons. Potrace also 
works reasonably well on text, provided that the 
characters have been rendered at a high enough 
resolution. Complex images are no problem, because 
Potrace is quite fast even on most large images. 

One thing that Potrace does not work too well on is 
noisy images. It is important to prepare the input 
image carefully to get best tracing results. I wrote 
another program called "mkbitmap" that can help 
doing this. It is distributed together with Potrace. 

Q - What is the current version of the software and 
are there further development charges planned 


The current version is 1.8. Potrace is quite stable at 
the moment, which means it works reliably and there 
is no need to make lots of changes to the software. 

Q - How can our reader help with the project 

Use Potrace and tell others about it! 

Q - is there a forum for people with problems using 
the software, can users email you directly 

For problems, users should first check the Frequently 
Asked Questions 

http://potrace.sourceforqe.net/faq.html 

and then use the Forum and 

http://sourceforqe.net/proiects/potrace 

Q - what are the main problems converting the 
software to other platforms, can you give a quick 
how to on conversion to our reader, is there any help 
on converting lets say an Amiga application to linux 
or even the PC, 

My main advice is to write the software portably in 
the first place. Fortunately for me, within the Unix 
community, there are some well-established 
standards for the programming environment that any 
Unix system should provide. One such set of 
standards is known as POSIX. Since POSIX 
environments are also available for Windows and the 
Macintosh, porting to those platforms was for the 
most part not very difficult. 

Q -1 presume that command line versions are quick 
to convert to other platforms is this why you only 
personally produced the command line 
version of Potrace 

No, portability was not a consideration in my decision 
to produce a command-line tool. Actually, I use the 
command line a lot. If I need to convert 200 images, I 
would much rather write something like "potrace 
*.pnm" than going through some graphical user 
interface where I have to manually click, drag, and 
drop 200 files. Tracing of images is not fundamentally 
an interactive process. Pretty much there is an input 
and an output, and a few parameters that one can 
tweak along the way. So I never saw the need for a 
graphical interface. However, others have written 
such interfaces for Potrace. 

See http://potrace.sourceforqe.net/#other 
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Interview with Steve Judd 

SLANG 6502 Programming Language 
http://www.ffd2.com/fridge/slang/ 


Q - What first introduced you to Computing and 
especially commodore 

I bought a C64+1541 in 1984 - in eighth grade - for 
$400 of saved up paper route money. I wanted to be 
a programmer but I wasn't very good at it; all I ever 
did were a few BASIC programs and eventually a few 
simple assembly programs that I never got to work. 
That left plenty of time for playing games, though. I 
stopped using it around 1988. In 1993 I bought 
a 128D, for old time's sake and to play games on, 
and wound up getting interested in 3D programs. 

This time however assembly language made 
sense, and it became possible to make stuff work 
and start having loads of fun. 

I probably became interested in computers via video 
games and computers in stores like Radio Shack; 
there were also computers at school, Radio Shack 
Model Ills. Like a lot of other kids my age, I can say 
that the C64 is what got me into the work I do today. 

Q - Please tell our reader a little about slang what 
it is and a general History of the project 

Slang is a programming language for the C64, and 
other 6502 computers. It's easy to learn and use, and 
compiles to pretty decent machine language for 
speed. It's meant to be used by everyone, from 
programmers just starting out who want to move 
beyond BASIC, to high-power assembly 
programmers who want to take some of the tedium 
away (writing a game engine, for example). Another 
hope was that it would encourage more C64 
programs to be written, by greatly reducing the 
development time and effort required. 

The project started around Jan 2004, and took some 
1 -2 years of pretty constant development. The code 
was developed in modules, for example the parser 
module, evaluating mathematical expressions, 
subroutines, etc. The code is all built on top of Sirius, 
an assembler that I wrote; that is, the compiler more 
or less translates code into assembly language, 
using the assembler to generate the code. (One 
result of this is that assembly language is built-in to 
Slang.) It looks like the very first beta version was 
released in Jan 2005, after a year of work. There 
were a lot of bugs, and missing features, so the 
program was continually updated for at least a year 
after that. 

The code was written in assembly language, on a 
SCPU-equipped 128D, using the Sirius assembler. 
There is something like a half-megabyte of source 
code, which is assembled to a file that is over 40k 
large, i.e. over 200 blocks of code (i.e. no graphics or 
music). 

Q - was the software solely produced by yourself 

Yes, but a number of people made great 
suggestions, found bugs, and so forth. Jaymz Julian, 
Majic Eyrie, and Christian Lott come to mind, and 
I apologize for others I've surely forgotten. 

Q - why was the software produced what prompted 
the project 


Hard to remember now, but... the main issue was to 
make it easier to write C64 programs. There are lots 
of assembly programmers who never write games, 
because game engines are such a pain in assembly. 
There are many more unfinished projects, because 
the development time is so long and involved. At the 
other end of the spectrum, there were motivated 
programmers who had a handle on BASIC but found 
assembly too difficult. 

The idea then was to create a language with a nice 
C64 vibe, which would be fun to use, easy enough to 
satisfy a BASIC programmer, and powerful enough to 
take on the most advanced programming tasks, 
making program development practical. 

Q - you must still be actively use commodore 
machines, what machines do you own and still uses 
(you can list none commodore machines) 

I'm afraid the 128 is in the closet these days. All we 
have at home is a Mac which I use for very mundane 
things like email. 

Q - must the software be run on a SCPU equipped 
Commodore machine 

The cross-development version, xlang, runs on Linux 
or Windows machines, and would probably run on a 
Mac if someone compiled it. Xiang actually emulates 
portions of the SCPU/C64 and runs the 65816 binary, 
as opposed to being a duplicate program. 

To develop on a real C= machine, however, a 
SuperCPU with plenty of memory is required. 

Compiled Slang programs run on a plain C64, and do 
not require a SCPU. 

Q - so is slang a new highlevel language like BASIC 
or is it more a low level language like machine code 

Both, actually. That is, it may be helpful to think of a 
set of layers. At the top layer, Slang is a high level 
language like BASIC, C, etc., and this is all a user 
ever has to see to use Slang effectively. All the 
usual high level features are present (variables, 
subroutines, logic control, etc.), and there are 
numerous C64-specific commands, such as 
commands to control sprites and interrupts. 

More advanced programmers, however, can take 
advantage of lower layers, getting closer to the 
hardware, writing new commands, and so forth. 

At the very lowest layer, Slang recognizes assembly 
commands, which may be mixed with regular Slang 
commands and variables, for the ultimate in flexibility. 
The web page contains example programs at these 
various levels. 

It should also be mentioned that Slang can 
communicate with outside ML programs very simply. 
For example, many years ago I wrote a set of ML 
routines for doing 2D graphics, such as lines and 
circles, to be called by other ML programs. With just 
a few lines of code I can now call all those routines 
as if they were ordinary Slang commands. This 
means that programmers don't have to re-write code 
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that they've developed over the years, but can just 
plug it in. 

Q - How would our reader start using the application, 
Does it need "installing” or is it just a case of copying 
a prg to a disk 

Most people would probably just download xlang, 
unzip the file, and be ready to go under Windows 
(DOS) or Unix. 

Q - the end code can it be run on none SCPU 
equipped machines or will the code only run on 
Commodore 64'swith a SCPU 

The compiled code does not require a SuperCPU to 
run. After all, the goal is to get more useful programs 
written, which means run on a stock C64. 

Q - Also is the code only Commodore 64 compatible 
or could you work on any 6502 processor machine 

Most of the code is plain 6502; only a few things, 
such as printing, or the C64-specific commands such 
as sprites, require a C64. Thus code may be written 
for 6502 computers other than the C64. Moreover, 
because of how the language is designed, it is 
actually possible to create completely new 
commands which are specific to other computers. 
That is, there could be an Atari-Slang, an Apple- 
Slang, and so forth. Nobody has been interested in 
this yet, though. 

Q - could you give an example of a simple program in 
basic and then in slang so our reader gets an idea of 
the syntax - although I will include the tutorial and 
quick reference from the website (if this is ok with 
yourself) 

(fine by me to include anything - everything on the 
web site is freely redistributable) 

Here is a short Slang routine, from the example file 
grdemo.c.s. It uses the grlib graphics routines to plot 
a sine wave: 

x1=0 

for x=0:60 step .1 
yl = 100+50.0*sin(x) 

GrPlotAbs(xl.yl) 
x1=x1 + 1 
next 

As you can see, the syntax is pretty straightforward 
and should feel familiar to anyone who has written a 
BASIC, C, or other high level language program.As a 
second example, here is some code from the 
example program spritedemo.e.s. It sets up a raster 
IRQ - when raster line 50 is reached, the subroutine 
"Scrolll" will be called: 

; Init scroll IRQ 

DisableTimerAIRQ ;shut down CIA timer IRQ 
(kernal IRQ) 

SetRaster(50) 

SetlRQRoutine(Scrolll) 

SetCol38 ;use 38 cols to make it smooth 

EnableRasterIRQ 

irq Scrolll() 

;irq routine code goes here 

While this is a fairly simple example, it demonstrates 
some C64-specific 


features of the language, and how easy it is to get up 
and running quickly. 

Q - The slang language uses libraries to compile the 
final code is this because the use of libraries is more 
efficient, can you explain libraries to our reader and 
the advantages 

Speaking very broadly, a library is a collection of 
code routines. These are typically commonly used 
routines - the "print" routine is an example. One 
advantage of using libraries is that they usually make 
code smaller: instead of duplicating a routine many 
times, a single subroutine is called each time. 

A second advantage is that it's easy to update or 
modify routines: instead of updating the entire 
compiler, I can simply update the library routine. 
Moreover, it now becomes possible for others to write 
their own collections of routines, and share them with 
others. Another, more technical reason, is that this is 
one of the ways Slang can be used to write programs 
for other computers: by writing an "Apple II" library, 
and substituting it for the "C64" library, it becomes 
possible to compile programs to other computers 
fairly easily.There is a more advanced feature, using 
the linker to create libraries, which are much closer to 
being "true" libraries, but it's more complicated and 
not worth going into here. 

Q - could our reader write his own library for use 
with slang, and is there a page to download more 
libraries for use with slang 

Certainly. Anyone can create libraries, or use 
libraries already created. Every library that I am 
aware of is available on the Slang homepage. 

Q - Where next then for the language? do you 
consider Slang to be stable so is it just a case of 
optimisation and adding more features 

Slang is pretty stable, and I haven't developed it for 
some time. The major problem has been getting 
people to use Slang. To date, I don't know of any 
finished programs written in Slang, aside from the 
example programs on the web page. Jaymz Julian 
had written a pretty substantial program, a Wizard of 
Wor clone, but it didn't get finished. (Life 
responsibilities probably took over.) Heck, I wasn't 
able to get even my friends to try Slang, or the 
people who asked for it in the first place, and I've 
received feedback from just two or three people. 
There just doesn't seem to be much interest, for 
whatever reason. So, I moved on to other things. 

I do still support Slang though, and I'm happy to help 
out anyone with questions. 

Q - Is SLANG free to download, 

Yes, Slang is free to download, and programs written 
in Slang are yours feel free to sell them, or give them 
away, or whatever, no different than using an 
assembler. 

Q - What support exists for users who need more 
help 

There is an online forum, and a mailing list, and you 
can always email me directly. 

> Q - Thanks for your time 

Thank you! 
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Slang Quick Reference guide 


Numbers and misc 


a=1234 
a=$1234 
a=%11010 


;comment 

;comment when in 1 st column 

;base 10 
;base 16 
;base 2 


a=a + & 
b 

a$="Howdy" 

a$=!5"hola"!13 

a$=!s"hey" 

petscii 


;line continuation 

;strings - " or' allowed delimeters 
;like chr$(5)+"hola"+chr$(13) 

;!s - use screen codes instead of 

;!r - use regular (petscii) codes 
;!n - negate (ora $80) following codes 
;!z - do not null-terminate string 


sub blah() ;Subroutine with no input or output 

variables 

sub blah2(int x, byte r) ;Subroutine with two input variables 
sub blah3(int z)<-byte s,int t ;Subroutine with one input 
variable (z) 

;and two output variables (s, t) 

sub blah4(@ax) ;One input variable, in the .A (lo) and 

.X (hi) 

registers. @x @a @xy @yx -> 

@(lo)(hi) 

endsub ;End subroutine (rts) 

sub asm chrout@$ffd2(@a ) ;Create subroutine 

interface ;(for calling 

external routines) 

Usage: 


Slang is CaSe InSeNsItlvE 

Variable types and declarations 

byte, ubyte ;1 byte, signed/unsigned 

int, uint ;2 bytes, signed/unsigned 

float ;5 bytes, MFLPT format 


blah3(10) ;Call subroutine on its own 

a=blah3<-s;Use subroutine variables in expressions 
b=blah3<-t + a + 1 

a=blah3(12)<-s ;can also combine operations 

Operators 

Note: comparison operators can be used with strings 


byte blah@$d020 ;@-var: locate variable at $d020 

int screen(25,40)@$0400 ;Create 2D array, locate at text 
screen 

int blah(3,3)=[ [1 2 3] & 

[4 5 6] & 

[7 8 9]] ;Create 2D array and pre-initialize 

values 

ubyte str(50)=['..can also use strings to pre-initialize'] 


blah(2,0) = 1 ;Note that array indices start at 0 


byte A test 

byte AA test2(20,10) 

test-ScOOO 

A test=10 

test2=$ 123456 

test2(3,5)=10 


;Create 16-bit pointer to a byte 
;24-bit pointer to byte array 
;set point location: Ida #$c000 sta zp 
;set location value: Ida #10 sta (zp),y 
;set array base address 
leading A not used with arrays 



;Assignment operator, e.g. a=1, c+=3 
;lncrement/decrement, e.g. blah++ 


bitand, bitor, biteor 
+ 

- * / A % 
and / 

BASIC 
« » 
float) 

<<=>>= = != 

1 


;bitwise operators 

addition, string concatenation 

;standard math operators. Note: int * 

;require core library; floats require 

;shift operators (note: fixed only, not 

;comparison operators. Returns 0 or 


and, or, eor;logical comparison operators. Returns 0 

;or nonzero (true). Note: identical to 
;bitand etc. but lowest 

precedence 

Functions 


deftype foo ;Compound variable type declaration 
int .a ;note leading . 

byte ,b(10) 
float .x 
defend 

type foo yakl, yak2 ;Create two variables of compound 
type foo 

yakl .a = 10 ;...which can then access individual 

elements 

yak.b(3) =-8 

yakl ,x = 3.1415926 

VarBlock @$c000 ;Define following variables starting at 

$c000 
ubyte tl 
int t2 

EndVarBlock ;until the EndVarBlock 

int b,c 

c=#b+3 ;Set c to the _address_ of b plus 

three 

Strings 


byte, ubyte, int, uint, float ;Type conversion 

a = int(x)+c ;Convert x to type int, then add 

floating-point functions: (BASIC ROM routines) 

abs ;absolute value 

atn ;arctangent (note: will rename as 

atan) 

cos ;cosine 

exp ;exponential 

trunc ;truncate 

log logarithm 

rnd ;random number 

sgn ;sign 

sqrt ;square root 

tan ;tangent 

misc functions: 

not logical not (0->1, nonzero->0) 

VIC functions: (may be used in expression) 
SpriteColSpr(number) ;Check spr-spr collision. Returns 
0/nonzero 

Flow control, loops 


byte str(20);Strings are byte arrays, null-terminated 
str(1) = 1 ;Treat as byte array 

str$="Hey!!"!13 ;Using the $ sign treats as string 


if str$(2:4) = "yi!" ;Can specify substring ranges 

str$(2)="blah" ;|H|e|b|l|a|h|00 

Subroutines 


note: <- indicates backarrow key; use _ (underscore) on 
PC/xiang 


Note: may be followed by a ! to execute the block when 
false : 


if! ;ifnot — if not true then... 

elseif! while! until! case! 

May be followed by + to use branch instead of jmp (if+, 
next+, ...) 

if (expr) standard if-block 

[code] 
elsif (expr) 
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[code] 

else 

[code] 

endif 

for x=start:end [step y] ;standard for-loop. step is optional 
[code] 

endfor -or- next ;next is alias for endfor 

while (expr) / endwhile standard while-loop 


repeat / until (expr) 
repeat / forever 

testall 

(inclusive test) 

testelse 

test) 

case (expr) 
case (expr) 
endtest 


standard repeat-loop 
infinite repeat loop 

;test all of the following cases 

;test cases like if-elsif-elsif (exclusive 

;execute following code if (expr) true 
;multiple case statements may follow 
;end statement 


Printing and I/O commands 

;Simple print (String print) - prints 


sprint [string] 
strings, 
sprintln 

sprint(10,3) "yo!" 

print 
library 

print !5"Hey!"!13 ;strings... 

print "x=" x" and y=",y ;mix and match, commas optional... 
print(10,3) "b=" float(b+10*sin(x)) ;expressions, (row,col) 
allowed 

println print, followed by CR 


pike sprint, but adds a CR at the end. 
print to row 10, column 3 

;Main print command. Requires core 


getchar b 
wait for char 
waitchar b 
waitchar 


;read a char, store in b. Does not 

;wait for keypress, store in b 
;wait for keypress 

;input a string using kernal CHRIN, 


Input b$ 
store in b 

InputStr(maxlen) b$ ;input using core library, max string 
length 
InputFloat x 
Inputlnt y 
dec/hex/bin 


;input float using core library 
;input 16-bit, signed/unsigned, 


load "filename",dev,address 
save "filename",dev,start,end 

Misc 


;load file to memory 
;save memory to file 


SetStrBuf address 
(default=$0200) 
SlangOut 
Slangln 

Interrupts 

irq name(varlist) 

IRQ routine 
endirq 
endsub 
jmpkernalirq 

Disablelnterrupts 

SetlRQRoutine(name) 

Enablelnterrupts 

EnableTimerAIRQ 
IRQ) 

DisableTimerAIRQ 
SetTimerA(value) 
AckTimerAIRQ 

EnableRasterIRQ 
DisableRasterIRQ 
AckRasterIRQ 
SetRaster(value) 

VIC commands 

UseSpriteStuff 
commands 


;Set location for string buffer 

;Compiler off (asm only) 
;Compiler back on 


;irq is an alias for sub - create an 

;...but end it with endirq instead of 

;or exit through the normal ROM IRQ 

;Disable Interrupts (sei) 

Set IRQ routine ($0314) 

;Enable (cli) 

;Enable CIA#1 timer A IRQ (system 
Disable 

;set CIA#1 timer A value 
Acknowledge timer A IRQ 

Enable the VIC raster IRQ 
Disable 

Acknowledge VIC raster irq 
Set raster value for IRQ to occur at 


;Enables below sprite 


;Set X-position for sprite 
;Set y-position 


SetSpriteX(#,xpos) 
number # 

SetSpriteY(#,ypos) 

SetSpriteColor(#,color) ;Set color 

SetSpritePtr(#,block) ;Sets the sprite pointer to block. Will 
be 

;updated in future to something more 

useful 


SpriteOn(#) 

SpriteOff(#) 

SetScrollX(value) 

(0-7) 

SetCol38 / SetCoWO 
SetCharData(address) 
data address 
SetVideoMatrix(address) 
address 

SetVICBank(bank) 
bank to 0-3 


;Turn sprite number # on 
;Turn it off 

;Set the fine x-scroll value 

;Set 38/40 columns 
;Set the character dot 

;Sets the video (screen) 

;Sets the 16k graphics 


MemConfig number ;Set memory configuration (location 
$01,0-7) 


poke 

wait address,value 
wait $d012,255 


similar to BASIC poke 
loop until address = value 
wait for $d012=255 


waitne, waitge, waitlt ;wait until address !=, >=, or <= value 


waitbitsclear 

clear) 

waitbitsset 


;addr AND value (wait for bits to be 
;wait for specific bits to be set 


fillmem(start,end,fill byte) pill a range of memory with a 
byte 


done / donebrk 

endsub 

endirq 

put 'filename' 
location 


;end program (rts/brk) 

;end subroutine (rts) 

;end irq routine (rti) 

PUT the file into code at current 


saveobj "@0:testcode.o" ;auto-save object code after 
compile 

autorun ;auto-run program after compile 

SetZPTemp address ;Set temporary ZP stack 
(default=$02) 

SetEvalTemp address ;Set temporary results 
(default=$0110) 


Linker 

REL - Assemble as RELocatable file. Placed at top of code. 
ENT - Declare label/variable/subroutine as an ENTry point 
EXT - Declare label/variable/subroutine as EXTernal 

Editor/Jammon (SCPU environment) 

Ctrl-h from editor brings up all available commands. 
SYS54016 will re-enter editor upon reset, etc. 

Please see the jammon docs (they're short!) for ML monitor 
details. 


Memory map 

$0801-$A800 
$A800-$CE00 
$CE00-$CFFF 
bank 2: 
bank 3: 
assembly 
bank 8+: 
hi bank: 


Slang core 

Compiler commands 

Used by slang for temporary results 

Temp: code assembled to bank 2 

Temp: vartab, storage during 

Editor text stored here 

Used to store slang environment 


Upon exit: 

- monitor in bank 0 at config.s address, if exited to monitor 

- PPPatch at $CE80-$CFFF or so 

- Re-entry code stored to $01d300 (SYS 54016 to restart) 

- Editor text moved up in memory as high as it can 

- Slang environment, etc. stored in highest available bank, 
e.g. on a 16M system this will be bank $F5. 
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A simple tutorial: 

Transitioning to Slang from BASIC 


If you're familiar with higher-level languages you can 
probably skip this part. Some people however may be 
familiar primarily with programming in Commodore BASIC, 
and that's who this section is targeted at. This section 
introduces some of the higher-level language features in 
Slang you'll need to be aware of, in comparison with BASIC. 

This is also a little tutorial on using Slang, so there are lots of 
examples below to try out. Once you've gone through them 
you should be well on your way to using Slang like a pro. 

Note: If you find this tutorial useful — or if you find it totally 
confusing - or if you find it anything at all - please write me 
or post a note to the forum, and let me know. I'd love to hear 
from you. Heck, right now I'd love to hear from anybody! But 
feedback is very important, and it helps me to know what 
works and what doesn't. 

Interpreted vs. Compiled 

BASIC is an interpreted language, whereas Slang is a 
compiled language. In BASIC, you write the code, then RUN 
it, then errors are caught as they are encountered (Syntax 
Errors, Overflow Errors, etc.). You can break a program 
while it's running, have a look at some of the variables, 
change things around, then CONTinue running the program. 

In a compiled language like Slang you write the code, then 
compile it into machine language, then run that machine 
language program. You don't actually run the code you've 
written - the compiler converts the code you've written into 
machine language, which you then run. 

So there are actually two parts to the program, that you can 
for example save to disk: the _source code_,which is the part 
you write, and the _object code_, which is what the compiler 
produces. The object code is what other people will run 
whenthey run your program. In Slang, source code files end 
in '.s', as in "spritedemo.e.s", and object files end in '.o', as in 
"spritedemo.e.o". 

As to errors, errors such as Syntax Errors are caught during 
the _compile_phase, before ever running the program. 

Other types of errors (called runtime errors) are never caught 
at all - in general if there are errors in your program it will 
keep on running, or may lock up the machine entirely! But 
Slang is designed to handle this, so that you won't lose your 
program. 

Tutorial lesson #1: 

So here is the first thing to try: we're going to write a program 
that will crash, so you can lose your fear right away of 
causing some huge problem. To start up slang, load and run 
the main program (slangbl.9.0 or whatever it might be). 

Once you've got the editor running, type in the following 
program: 

sprint "here comes a crash!" 
donebrk 

Then press FI to compile the program. If there are no 
errors, you will get a "compile successful" message. Now 
press F4 to run the program - 


crash, right? Go ahead and reset the machine (don't power 
it down; just press the reset button). Then type 
sys 54016 

and you should pop back into Slang. Slang stores itself up in 
SuperRAM, so you don't need to worry about losing your 
program because of a crash, and if you want to try 
something just go ahead and experiment! 

Variables 

In BASIC variables are created on the fly -- you just say "10 
a=1" and off you go. In languages like Slang, you have to 
declare your variables before using them. Let's take a dumb 
BASIC program, and convert it to Slang: 


10 FOR B=1 TO 3:PRINT "BLAH ";:NEXT 
20 PRINT CHR$(13)+"PRESS ANY KEY" 

30 GET A$:IF A$="" THEN 30 
40 END 

Obviously lines 20-40 are not needed, but I put them in for a 
reason. Here's a Slang version: 

byte b 

for b=1:3 
sprint "blah " 
next 

sprint !13"press any key..." 
waitchar 

done 

Tutorial lesson #2: 

Go ahead and type this program into the Slang editor, press 
FI to compile, and press F4 to run. Easy! The first line of 
this program _declares_ the variable. Part of the reason you 
have to do this is that there are different _variable types_ 
available. In BASIC, you can have floating-point variables, 
integers, and strings, and the name itself tells basic what 
type of variable it is: 

a=10 ;numeric (floating point) variable 

a%=10 ;numeric (integer) variable 

a$="10" ;string variable 

As you probably know, the only reason to use integer 
variables is with arrays, to save memory, because an integer 
array takes less memory than a float. Otherwise, a plain 
integer variable takes exactly as much space as a regular 
variable, and is actually slower for calculations because all 
calculations in BASIC are floating-point calculations. 

In Slang, this is not the case. The variable type not only 
changes how much space is used but also how the variable 
is manipulated. In Slang, adding integers is much faster than 
adding floats together, and the integers take less space. For 
example, if you change the line 

byte b 

in the program above to 
float b 

you'll find that the program becomes larger, and it's also 
much slower (although you won't notice that in a simple 
program like this). 

Tutorial lesson #3: 

Change b from a byte to a float, compile, and see 

what happens. The different variable types available in Slang 


byte -1 byte, signed numbers in range -128..127 

ubyte -1 byte, unsigned, range = 0..255 

int - 2 bytes, signed, range = -32768..32767 

uint - 2 bytes, unsigned, range = 0..65535 

float - 5 bytes, signed, range = well, the usual BASIC 

range 

In general, the smaller variables are also faster, so you'll 
often choose the simplest variable that meets your needs. 
Just a few other things are worth noting. Unlike BASIC, 
variables can also 
have really long names, like: 

uint ThisisAVeryLongVariableName 

b = b+ThislsAVeryLongVariableName 
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Note also that variables can mix upper and lower case (the 
compiler is case-insensitive), and can mix variables of 
different types (you can add a byte to an int, for example). 
And once a variable is declared, that's it — you can't re-define 
a variable as a different type. 

One other thing to notice is that there is only one statement 
per line. Unlike BASIC, you cannot put multiple commands 
on the same line. 


Loops and such 

As is apparent in the above program, the for-loop in Slang is 
pretty similar to the BASIC for-loop. You can also put a 
"step" in there: 

for b=1:10 step 3 

There are two other loop structures available in Slang (and 
many other lanauges): while-loops, and repeat-loops. Here's 
an example: 

b=1 

while b<4 
sprint "blah " 
b=b+1 
endwhile 

This program does exactly the same thing that the for-loop 
does in the original program: while the expression b<4 is 
true, it performs whatever 

code is in-between the "while" and "endwhile" statements. 
The repeat statement is very similar: 

b=1 
repeat 
sprint "blah" 
b=b+1 
until b>3 

A repeat-statement always executes at least once, because 
the expression check is at the end of the loop. The way to 
think about all these things is pretty simple: 


while [expression] While [expression] is true 

[code] <- Execute this block of code 

endwhile between the while and endwhile 

statements 


One thing that Slang does not have is a GOTO statement. 
You can actually do gotos using assembly language, but it 
turns out that you can handle all the things you might use 
GOTO for using for/repeat/while-loops and the if-endif 
structure discussed down below, and your programs will be 
easier to debug. 

Tutorial lesson #4: 

Replace the for-loop in the example code with a) a while- 
loop, and b) a repeat-until loop, but make it print out the text 
five times instead of three. Compile and run each case to 
verify that it works. 

Ending a program 

You'll notice that the program ends with the line "done". In 
BASIC, putting an "END" in is optional. In Slang, it is 
required. It tells the C64 how and when to exit the program. 
If you'd like to see what happens when you leave it out, go 
ahead and try it! Just remember that "sys 54016" will restart 
Slang after you reset the computer. 

We can now explain the last few lines as well. The 
command "waitchar" simply waits for a key to be pressed. 
Without this line, the program would immediately end and 
return you back to Slang. The "waitchar" would not be 
necessary if this program were being called from, say, 
BASIC — in thatcase, you would probably want control to 
return to BASIC immediately. 

But when running programs directly from the Slang editor, 
you'll usually wantto put a line like this at the end of the 
program. 

Tutorial lesson #5: 

As a test, go ahead and comment out that line (place a 
before the waitchar), re-compile, and see what happens 
when you run the program! 


Print 

The little program above used the "sprint" command. There 
are actually two print commands in Slang: print, and sprint. 

Sprint — Simple Print, or String Print - is a simple print 
command that only prints strings (not numbers). As we shall 
see shortly, the regular print command contains certain 
things in a _library_, which requires an extra step, and will 
make your programs larger. For the moment though we can 
focus on sprint. 

Printing a string in Slang works much the same in BASIC, 
with just a few little twists. Unlike in BASIC, you cannot 
embed special characters inside the quotes, like 

10 PRINT "{ctrl-2}{shft-clr}nice white text on a clear screen." 

Instead, in Slang, you have to use the character codes 
directly; in BASIC, you could also do the above as 

10 PRINT CHR$(5)+CHR$(147)+"nice white text on a clear 
screen." 

In Slang, you simply use a I instead of chr$, so this would 
look like 

sprint !5!147"nice white text on a clear screen." 

The above command has one key difference from the BASIC 
version, however :in BASIC, PRINT normally prints a 
chr$(13) at the end of the line, whereassprint will not. It turns 
out that there's actually two more print commands in Slang, 
though: println and sprintln. These work exactly the same as 
print and sprint, but print an extra [RETURN] character at the 
end. 

Tutorial lesson #6: 

Go ahead and try replacing "sprint" with "sprintln" in the 
example program,and see what happens. 

Tutorial lesson #7: 

Modify the example program to print out the text in cyan. 

How about light green? 

There's one more trick to print and sprint: you can specify 
_where_ on the screen to print: 

sprint(0,20) "some text" 

will print the text at row=0, column=20. 

Tutorial lesson #8: 

Modify the program to print the text to the middle of the 
screen. In contrast to sprint, print can print numbers and 
strings, and you can stick them all together on a single line. 
The catch is that manyof the routines needed to do this are 
in a _library_. This library is a file on the disk, containing 
special routines. In general, libraries can be source code, 
object code, or a special kind of file (a relocatable 
file) for use by the linker, which I won't talk about here. 

Tutorial lesson #9: 

What we are going to use is a simple source code file. Try 
typing in the following code, and compile and run it: 

byte b 

for b=1:10 
println "b=" b 
next 

print "press any key..." 

waitchar 

done 

put 'putcore.e.s' 

The two critical differences here are 1) we are now using 
print instead of sprint, and 2) the "put" command at the end 
of the file. 

For now, instead of going into detail on PUT, let's just say 
that you need that line at the _end_ of your code - after the 
done statement - if you want to use the full print command. 
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Notice that we have put both a string and a number on the 
print line, similar to BASIC. You can also separate these 
with commas, if you like: 

print "b=",b 

It just depends on which way you think is clearer. You can 

also print to 

any part of the screen: 

print(b,20) "this is row "b 

Tutorial lesson #10: 

Replace the println statment with the above "this is row" 
statement, and see what happens. 

As you can see, print is much more powerful and flexible 
than sprint, but the downside is that you need to PUT the 
core library in there, which increases compile time and 
makes the program much larger. Experience will help you 
figure out when you want to use one or the other. 


The core library 

Above we used the core library, using the line put 
"putcore.e.s” at the end of the program (whether you use ' or 
" quotes doesn't matter, incidentally). This is a very 
important library and is needed for more than just print. 

Tutorial lesson #11: 

Multiplication and division of bytes/ints requires this library, 
and you will get an error if you don't include the core library. 
(Print will also generate an error.) Try the following program: 

int b 

b=10 

b=b*2 

done 

Now compile it, and you will get an error at the multiplication. 
Then add the line 

put 'putcore.e.s' 

to the end of the program, compile... and it will work. And 
since you're including the core library anyways, you can go 
ahead and print out b if you want to. 

Why use a library? If you know BASIC, you know that a 
command like "print" actually calls a routine in the BASIC 
ROMs to do its thing. The BASIC ROMs are, for the most 
part, one big library, but they are in ROM instead of in a disk 
file. 

Sometimes machine language programmers will call these 
BASIC routines instead of writing their own. Similarly, in a 
compiled language like Slang, sometimes it makes sense to 
call a common routine to perform some task. A library is 
nothing more than a collection of useful routines. 


Arrays and Strings 

We're just about done here. I'm not going to cover _all_ of 
the available commands; the goal here is to get across the 
major commands, and then youcan browse the slangref.txt 
document to check out other commands. So I'll just touch on 
the remaining topics at this point. Arrays in Slang work much 
the same as arrays in BASIC. You declare them 
very similarly to other variables: 

int b ;regular variable 

int c(20) ;array 

This is similar to using the DIM statement, if that helps. 
There's just one thing to remember: array indices start at 0. 

In the above declaration, 

you can address c(0), c(1), c(2), ... c(19), like 

c(19) = 1000 

but 

c(20) = 1000 
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will be incorrect (and may cause a crash). There are 20 
elements total: 0 through 19. If it's too confusing, then one 
thing you can do is to add one extra element to any array - 
like, use "int c(21)" -- and not worry about it. 

Strings also are really similar to BASIC, but you're going to 
have to get one thing straight in your head: strings are really 
just bytes. There is no "string" type, like byte/int/float; strings 
are just bytes. 

You already know this, from BASIC: 

d$="a" treating letter "a" as a string 

d$=chr$(65) treating "a" as the number 65 

The letter "a" is really just a number - 65 in this case. This 
works the same way in Slang: 

ubyte d 

d = "a" ;a "string" 

d = 65 ;a number 

That's fine for just one character, but that's not a string. In 
Slang, a string is just a byte array: 

ubyte d(20) 

d$ = "hello" ;treat as a string 
d(0) = "y" ;change string to "yello" 
d(0) = 67 ;change string to "cello" 

In this example, d is a byte array. You can treat it as a 
string, or as a list of numbers. As in BASIC, the "$" tells 
Slang to treat the variable as a string - I won't go into the 
details about this, but I think the meaning is pretty clear from 
the above example. 

Tutorial lesson #12 

Here's a simple program using strings to try out: 

ubyte d(20),i 

d$="hello" 
println "d$=" d$ 
d(0)= 67 
println "d$=” d$ 
for i=0:5 
println d(i) 
endfor 

waitchar 

done 

Go ahead and play around with it - try adding 1 to each 
element of the string, etc. One important thing to note: when 
you run the program, you'll notice that the last number 
printed in the for-loop is a 00. With strings, the very last 
element will be zero -- this is what tells Slang where the end 
of the string is. If you overwrite this ending zero, you'll 
generally get a whole bunch of garbage. So... 

Tutorial lesson #13 

Change the line 

d(0)= 67 
to 

d(5)= 67 

and see what happens when the string is printed. This 
overwrites the ending zero byte, and should in general print 
out a bunch of garbage. Sometimes, 
if you're lucky, there will be another 00 somewhere in the 
array! 

If-elseif-endif 

The if-then structure: 

if a=10 
do something 
elseif a=11 
do something else 
endif 






Commodore Free Magazine 


It's similar to the BASIC command, except that you have an 
elseif or endif command to mark the block of code to be 
executed, just like while and repeat. 

Subroutines 

In BASIC, you are familiar with GOSUB -- it calls a 
subroutine, and then RETURN returns back to the place of 
the subroutine call. Slang subroutines are more 
sophisticated, but the idea is the same and overall they are 
pretty similar. 

A subroutine is like a mini-program: you can define variables, 
have a bunch of statements, etc. The neat thing is that these 
variables and statements are _local_ to the subroutine -- 
they "belong" to the subroutine, and do not interact with other 
subroutines. This allows you to organize your programs 
efficiently. 

Just like a variable, you have to define a subroutine. And 
you need to end the routine using "endsub". 

With a subroutine, you can pass _parameters_ to the routine. 
For example, the graphics library has a routine called GrPlot, 
to plot a point. And it requires two parameters: the x- and y- 
position of the point to be plotted: 

GrPlot(x1,y1) 

Subroutines can also pass parameters _back_ to the calling 
routine. Once you "get" the idea of parameter passing, and 
of local variables, the rest is a cinch. 

Tutorial lesson #14: 

Type in and run the following program, which demonstrates 
the idea of local variables within a subroutine: 

byte b 

b=1 

TestRoutineQ ;Call the subroutine 
println "but in the main code, b is still "b 
waitchar 
done 

sub TestRoutineQ ;Define the subroutine 
byte b ;create the _local_ variable b 

b=10 

println "in the subroutine, b="b 
endsub ;end subroutine 

put "putcore.e.s" 

You can see what I mean about a subroutine being a mini¬ 
program. Within the subroutine you declare variables, have 
statements, and end it with an endsub. You don't really 
worry about what other routines or the main program does; 
the subroutine doesn't "see" them. 

So, a few observations: the "sub" keyword defines a 
subroutine. We _call_ the subroutine by simply typing the 
subroutine name in the main program. Once the routine 
finishes, the calling program continues executing where it left 
off. 

The subroutine declares its own variable b. Even though it 
has the same name as the variable in the main program, this 
is a _local_ variable; it "belongs" to the subroutine, not to the 
main program. 

Tutorial lesson #15 

In this lesson, we'll try parameter passing. 

int xl.yl 

x1=12 

y1=20 

AddEm(xl.yl) 

println "the result was " AddEm<-result 

waitchar 

done 


sub AddEm(int a, int b)<-int result 
result = a+b 
endsub 

put "putcore.e.s" 

(As before, <- is the backarrow key). 

In this example, the subroutine AddEm takes two _input_ 
parameters, a and b, and has one _output_ parameter, 
result. As before, all three of theseparameters are local to 
the subroutine, so they could have the same name as 
variables in the main program. 

With the return parameter, what we are really doing is 
making a subroutine variable _visible_ to outside routines. 
Normally all variables and such inside a subroutine belong to 
the subroutine, and are not available outside of the routine; 
this is how to make specific ones available outside of the 
subroutine. Just as with input variables, there can be a 
whole list of output variables. 

Back in the main program, this is just another variable called 
AddEm<-result. You can use it in expressions, etc. just like 
any other variable: 

xl = xl + 2*AddEm<-result 

So in summary: a subroutine is like a mini-program, with its 
own variables and statements. But, you can pass 
parameters into the subroutine, and youcan retrieve 
variables out of the subroutine, as needed. Subroutines are 
really helpful in organizing and simplifying programs, so it's 
well worth taking the time to understand them if you don't 
already! 


Saving object code 

Once you've written a program, what do you do with it? 

What we're going to do here is save the _object_ code, and 
then load and run it. 

Tutorial lesson #16 

(always need some multiple of 16, right?) 

Compile one of the example programs above (one that 
works!). Once it compiles successfully, press F7 to enter the 
disk menu. First, save the source code by pressing "s". Go 
ahead and enter some filename; the program will 
automatically append a ".s" to the filename. 

Second, save the object code by pressing "o". You'll see the 
same filename as default, so go ahead and press return. If 
you now list the directory, you should see two new files: one 
with a .s, the other with a .o. You can now load and run the 
object code totally indepently from Slang. 

Exit back to the editor. We are now going to exit to BASIC: 
press shift-ctrl-<- (backarrow, to the left of the 'T key), and 
you should be back at the BASIC prompt. If you'd like to try 
your program from here, you can type "sys 4096". 

Now reset the machine. Go to the disk directory, and load 
your object file ,8,1. 

Your object code is a machine language file, just like other 
programs you may own or download. Once it's loaded, type 
"sys 4096" to run it. (By default, Slang programs are located 
at 4096, but it is easy to locate them elsewhere, such as 
32768 or 49152, or even make it so you can RUN them from 
the BASIC prompt.) 

When you're done, type "sys 54016" to return to Slang. 

And that's it! You should now be able to write, run, and save 
Slang files and be well on your way to writing new programs. 
If you have any problems or questions, don't hesitate to write 
me or to post to the forum! 

Good luck! 
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Interview with Nick Coplan 
Creator of HDD64 

http://www.64hdd.com 


Q - Please introduce yourself to our reader 

Hi! I'm 38, a mechanical engineer by profession - but the 
C64 lets me follow my true passion which is electronics and 
programming. I first got a C64 when I was in high school, 
aged -16. 

Q - What is it you do for the Commodore world 

I'm probably most well known for 64HDD a PC program that 
lets your C64 use the PC as a hard disk drive. I also provide 
other tools and hardware stuff. 

Q - Please tell our reader about DriveGhost and 64HDD 

64HDD is a program which lets you use your PC as a hard 
disk drive for the C64 and other Commodore computers with 
a serial disk port such as the VIC20, Plus/4, etc. It emulates 
the native protocol these machines use to talk to drives like 
the 1541 so the computer doesn't need to be patched or 
wedged in order for basic disk commands to work. It also 
emulates the various Commodore disk drives at a 
basic level allowing for various disk images to be used, for 
example D64, D71, D81. 

It has some more powerful native modes and can support 
commands which were part of the CMD product range. It 
lacks a CPU emulation module and as such cannot run any 
specialised disk commands which execute code "in the 
drive". All that's needed is a XE1541 cable to connect the PC 
and Commodore, the free software download and of course 
a PC which can be booted to MSDOS (you can do that even 
to modern PCs with a boot disk). 

DriveGhost is a C64 program which works with the CMD 
drives and 64HDD allowing data to be transferred between 
these drives. The transfer is at the disk level (rather than file 
level) and so it is an imaging or “ghosting” system. The idea 
is to “image" the CMD drive to the 64HDD PC, from where it 
can be burnt to CDROM as a backup. I’ve found it most 
useful as a means of backing up my RAMLink and 
restoring different projects to it either on a partition or whole 
device basis. 

Q - Isn't using a PC for backup and loading applications a 
little like worshipping the devil 

Some find it a wonderful irony to make a "modern powerful 
machine" act as a slave to a humble 8bit machine from 25+ 
years ago ;) 

Q - Has anyone commented about the use of a PC 

A few do and some don't like the concept of having to have 
the PC hardware (a second computer) next to their C64 
setup for space reasons. On the other hand, many have 
followed my example and build 64HDD into an embedded 
system - that is a box that needs no screen or keyboard. You 
can get those IDE2CF adaptors which means your PC box 
can boot and run off a CompactFlash card making the whole 
unit quite compact. 

Q - Can the software work on anything else 
Mac/Linux/Amiga 

Unfortunately not, and I have no intent to reprogram it to 
support these operating systems. The problem is that 
because of the very critical timing protocol, so much of 
64HDD's core is dependent on machine specific assembler 
code. 

Q - What started you programming 

In a general sense? I guess I've always enjoyed creating 
things, be that with Lego, wood, metal, design or art. 
Programming was another way to "create" something. Back 
when I started coding (the C64 was my first computer) I 
coded mainly applications, but a few games. I've kept 


programming ever since, but usually moved from project to 
project once I’ve taken something to its finish. 

Q - Why are people still producing hardware/software for the 
Commodore 64/128 Hardware 

It is fantastic that there is still new stuff coming out! The 
market is not that big, but the users out there I feel want to 
prove that their C64 is "still up to the task". 

Q - Tell our reader about 64HDD Speed-Up Cartridges 

These cartridges quite simply allow you to load programs 
(including compatible multi-part programs) at speeds far 
greater than the normal 1541/IEC protocol allows. They're a 
bit like the Epyx FastLoad cart was for the 1541, but 
specifically for the 64HDD system. 

Q -1 have been looking to purchase on of the "64HDD 
Speed-Up Cartridges" but the different configurations 
confuse me can you explain what the different versions are 
and what our reader needs to do, for example I think 
originally you needed to check various chips within the C64 
is this still the case. 

Basically users have two choices - serial and parallel. The 
serial speed-up (Turbo/XE) needs no special cable since it 
works perfectly with the industry standard XE1541 cable. 

The parallel options are far faster than the Turbo/XE, but 
either require you build/buy a parallel cable or go for the 
Pwr/Link option (which has the cable interface built-in). 

The only time you need a special version chip of the carts is 
if you have both a SuperCPU and RAM/Link - since this 
combo reads the IO area of the expansion port at a faster 
than normal rate. The cartridges are far easier to install than 
the internal Kernal ROM upgrade which has been available 
for a while. There’s a few other options, but that about 
summarizes the basics... 

Q - Commodore Gaming have introduce a new line of PC 
systems with Commodore logos what are your views on this, 
could it be a good thing. 

It’s always great to see the Commodore name still in use, but 
I must admit that I think of these being "just a PC". Gone are 
the days that the Commodore brand 

had a different OS and hardware architecture that meant you 
could compare to your friend's Amstrad or Atari. 

Q - We know the Commodore 64 had some interesting 
design workarounds (some would say flaws) also revising 
models and changing designs and revisions of the main 
board, can you explain about problems you have 
encountered getting your hardware and software to work. 

The main challenges I've had have been due to the different 
ROM configurations on the various build boards, and the lack 
of consistency when it comes to whether these chips are 
socketed or soldered. This makes it hard to upgrade some 
C64s. It also some makes internal upgrades very different 
from machine to machine. From a programming viewpoint, 
the main problem I had was found years ago with some of 
my early games and the screen clear bug which is different 
between kernals vl and v3. 

Q - Did you work with Maurice Randall to produce the GEOS 
extensions for the 64HDD 

The original 64HDD-GEOS drivers were independently 
developed on the reverse-engineered GEOS code produced 
by YTM. The GEOS-XP drivers were re-written from scratch. 
Maurice's articles in the Commodore World magazine 
provided some helpful GEOS programming advice, but did 
not directly help with building disk drivers. Maurice has an 
example of a Wheels disk driver on his distribution, but I’ve 
not tried any Wheels programming yet. 
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Q - Maurice had a special version of GEOS for the 64HDD 
what advantage does the 64HDD provide GEOS (apart from 
speed) 

The only difference between the versions of the drivers on 
the CMDRKEY website and those on the 64HDD website is 
that the former version is pre-keyed to the GEOS v2.0 
distribution which Maurice provides for free download. Due to 
GEOS licensing rights, Maurice does not allow these to be 
hosted elsewhere, but has been kind enough to host them 
for me. If users want to try the basic GEOS config and have 
no extra licensed GEOS to key-in its easiest if they try these 
D64s from Maurice’s site. 

Q - Can you explain to our reader some of your other 
hardware/ software products 

Other than 64HDD and DriveGhost related... Hmm, well I’ve 
built a number of smaller interfaces for things such as 
controllers, etc. There’s the MegaCart - a 1 MB cartridge 
configured to store upwards of 64 Commodore cartridge 
ROMs (in ROM not transferred to RAM). I’ve dabbled with 
DTV, TurboProcessor, IDE64... The www.64hdd.com site 
also has a bunch of tools I've developed over the years for 
my needs which others might find helpful. 

Q - Some of our reader may like to ask the question "selling 
all this hardware and software must have made you very 
rich" how big is the Commodore market 

The Commodore market is not very big, its also seasonal - I 
find people stock up just before the northern winter season 
so they have something to do whilst coupled up inside . As 
for the money, near all I've made has been re-invested in my 
hobby - buying more Commodore equipment! It's a classic 
case of what comes around, goes around - I’ve bought 
things from near everyone selling new Commodore 
developments/projects as well as heaps from eBay. 

Q - Mega Game Cartridge looks like a great idea, although 
we have seen similar, what is special about your version. 

At the time the MegaCart was released it was pretty much a 
first of its kind. The difference between it and the followers, 
for example the RetroReplay and MMC64 is that various 
games are stored in read only memory (ROM) and the menu 
system. Being in ROM, the CRT images do not need to be 
patched for the copy protection code embedded into some of 
them. 

Q - Can the Mega Game Cartridge be programmed with your 
own games, If so how is this done 

The MegaCart can be reprogrammed, but must be done 
using an EPROM programmer. The menu then requires a 
little bit of reprogramming to setup titles and cartridge 
settings such as /game and /exrom lines. Not exactly do it 
yourself. Those that bought the few I made wanted games in 
the original unpatched format in a format that saved on the 
storage and wear-n-tear on their originals. 

Q - What is the next project then? 

Hard to say... there’s a lot on the go, but not ready enough 
to promise. Also, of late family has taken priority. I can tell 
you about some of the wacky-one-offs which probably won’t 
see “mass production”. There’s an internal 16MB expansion 
- being internal means the VIC chip can see all of it, unlike 
with the SuperCPU in which the VIC is limited to the 
standard 64k. There was the internal 65816 processor. USB 
interface (hardware only, never got to the software) 

Q - Maurice Randall seem to be over worked and very slow 
to deliver orders, have you ever wanted to produce "similar" 
products 

I've thought about it, even offered to build them under licence 
from Maurice - but that didn’t suit him at the time. Of the 
CMD products, it’s mainly the SuperCPU which hasn’t been 
matched or superseded by modern day alternatives. 
Unfortunately for the SCPU, GEOS is the main reason and 
very little alternative software has taken advantage of it. 
Wings tried, and Clips looked promising, but was never 
finished... 


Q - Have you met Maurice, and have you asked him about 
CMD 

I met Maurice at the SWRAP expo back in 2001, and have 
had correspondence with him before and since. I’ve not 
specifically talked about CMD, other than to 
offer support. He's always been helpful. 

Q - What is the design process for your hardware projects 

Step 1 in the process is to begin with something I want. I 
don’t usually design for what I think will sell as there's no 
guarantee that the project will ever get to that stage. If what I 
build for me seems popular to others I consider the options 
for making more than the 1-off. 

Generally selling volumes are low, so hand built is the 
usually production method. Things like the 64HDD speed-up 
carts have proven more popular and so specialised PCBs 
have been made allowing for prices to drop. 

Q - How long did let's say the MegaCart take from design to 
finished product 

That was one of the quicker ones... I’m guessing about 
3months. The original was pretty quickly built by recycling a 
SuperGames cart, but the more games / programs I found 
the more quirks I found about the memory config these 
programs expect at power-on and how they use this 
information as a way of copy 
protection. 

Q - Are you ever 100% happy with your finished products or 
do you think, I wish I had more time to implement xxxyyy or 
tweak xxxaaa before having the item mass produced 

Surprisingly I've had very few recalls or upgrades to existing 
hardware products, which I guess means they were well 
proven before release. Its part of the design philosophy of 
building to satisfy my needs, before offering the item for sale. 
I guess I must be my own “toughest” customer. Software 
upgrades are a different thing, and that’s why both 64HDD 
Professional and DriveGhost come with free upgrades. 
Mostly the upgrades are new features, rather than bug fixes. 

Q - After the prototype, who do you contact to create the 
circuit boards, and how do you know the amount to order 

I use a mail order company for the circuit boards, they're 
reasonably fast and happy to do small production runs. It is 
hard picking a quantity to order. Order too many means 
cheaper price per board, but I can’t afford to stock pile too 
many. I usually design the boards to suit a number of 
purposes by changing a few jumpers. This helps increase 
their adaptability meaning I can use them for another 
purpose if something is not a big seller. I usually order 20, 
and if they get sold, another 20, and so on. 

Q - Have you ever prototyped a design then taken it to be 
mass produced and they have said "we can’t make that" or 
"it will be to expensive" 

The mail order place I use has an on-line quoting system so 
I’m usually able to get that info worked out before going to 
far... Because of the low batch sizes price per board needs 
to be weighed against the only other option I would have 
which is point to point hand soldering. Sometimes hand 
building something works out cheaper than a simple board. 

Thanks for the chance to “talk” to your readers... 
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Jim Butterfield: 

The Commodore Guru - An Interview 
Copyright 1996, 1999 by Jim Lawless 

This article originally appeared in Commodore Hacking #14. 

http://www.radiks.net/~jimbo/art/c642.htm 


My initial interest in the Commodore 64 computer 
began in 1983. At the time, my primary source of 
information pertaining to the C64 came from 
Compute! and Computers Gazette publications. One 
author's name stoodfrom the rest; Jim Butterfield. 

I used to turn to Jim's articles immediately when I 
managed to get my hands on a new magazine. Mr. 
Butterfield has the rare ability to describe complex 
subjects in simple terms. 

I'm certain that I'm not alone when I credit Jim with 
having taught me a lot about the inner workings of 
the Commodore 64. As important as the specifics of 
writing code for the C64 was Jim's style. He would 
often write code that was readily portable to multiple 
CBM machines. His code had longevity and purpose. 
The solidity of his programs left me with a lasting 
impression pertaining to how software should be 
developed. The following interview with Jim was 
conducted via e-mail. 

Q: What was the first programming language that you 
learned? 

A: In about 1963, an assembly language called 
COGENT for a computer that few people have ever 
heard of: a Collins Radio C-8401. That was shortly 
followed by work on an IBM 1401, which had a 
machine language that was alphanumeric. (Honest! 
You could keypunch M/L directly!) 

Q: Were numbers expressed in Base-36? 

A: No. Decimal. 

The basic machine had 1000 bytes (not IK) of (7-bit) 
memory (core, not RAM!) so addresses ranged from 
000 to 999 (and were given in decimal, of course). 
Expanded machines had 4K, then 16K ... the 
addresses were slightly more complex in that case. 
Thus, to move bytes from an area at, say address 
123 to address 456 the instruction would be 
M123456. I AM NOT MAKING THIS UP!!!! 

Q: Did you guys have contests to spell out goofy 
words as part of a program? (I know of a programmer 
who used to regularly use the return code $0BAD to 
indicate a problem...) 

A: No (the addresses mixed in with the op codes 
ruled that out), but you could do fun things on a 1401 
if the system manager wasn't looking such as play 
music. 

Q: What was the first computer that you owned? 

A: Not counting the TUTAC-1, which was powered by 
rubber bands and was more correctly a logic 
machine: The KIM-1, a single-board microcomputer 
made by MOS Technologies, Inc., of Norristown PA. 
MOS Technologies was subsequently acquired by 
Commodore. 


Q: When did you first encounter a Commodore 
computer? 

A: When Commodore acquired MOS Technologies, 
the computer that I had owned for over a year 
became a Commodore computer. Subsequently, an 
employee of MOS Technologies, Chuck Peddle, 
convinced Jack Tramiel of Commodore that they 
should launch a personal computer called "The PET". 
I got one of those not long after they started 
production. 

Q: Did you have formal training in computer 
programming? 

A: Yes, on that long-ago Collins C-8401. But this was 
more a process- control machine; it didn't use of any 
the newfangled (at the time) languages such as 
Fortran and Cobol. So my training was in machine 
language/assembler. 

Q: What was the first book that you wrote? 

A: A couple of enthusiasts and I collaborated on a 
volume called "The First Book of KIM", a book 
describing how to do things with the KIM-1 single 
board computer. That computer was powered by a 
6502,by the way; in fact the KIM-1 board itself was 
designed as a engineering prototype for people who 
wanted to try out the chip. 

Q: Was it similar to the Altair where you had to 
manually increment an address-counter before you 
could throw the switches to set the byte at 
that address? 

A: No, the KIM-1 had an operating system in ROM. 
That's one of the things that made all KIM users 
"equal" and able to share programs, while the other 
early micro owners had quite a scattering of stuff. 

Q: What COULD you do with a KIM-1? 

A: Hey, watch it! That's like saying, "What could you 
do with a Commodore 64"? Although the KIM-1 came 
with a hexadecimal keypad rather than a keyboard, 
and output to a six-digit LED display, you could use 
those to good advantage AND hook up extra stuff. 
Play music? Play Blackjack? Hunt the Wumpus? 
Skeet shoot? Unless you had the budget for a 
printer, you’d have a hard time doing an accounts 
receivable, of course. But this is the 6502 we're 
talking about! And we all know it can do ANYTHING! 

Q: What was the last book that you wrote? 

A: It's probably the revised version of "Machine 
Language For the Commodore 64, 128, and Other 
Commodore Computers". In 1985 and 1986, 
however, I did produce a "pocket diary" reference 
guide for Commodore 8- bit computers. 
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Q: Have you ever written articles or books on 

subjects that are not 

computer-related? 

A: My first writing experience was a treatise on 
transistor theory, published by Popular Electronics in 
August of 1959. Not much else. 

Q: Did you write commercial software for any of the 
Commodore computers? 

A: As a general rule, no. All my stuff is public domain. 
At one time, I had written a simple spell-checking 
engine that was incorporated into a word processing 
package for a while. 

Q: SuperMon was a tool that I used daily when 
developing ML routines or exploring the C64. What 
prompted you to write SuperMon? 

A: In the early days of Commodore personal 
computers, there were quite a few machine language 
monitors around. They were partly based on some 
publicly published code by Steve Wozniak (of 
Apple!), and partly based on the MOS Technology 
TIM monitor, from KIM-1 days. 

Two variants of the basic monitor caught my eye: 
NewMon, which added several useful features to the 
basic Machine Language Monitor; and HiMon, which 
sited the monitor in upper memory where it wouldn't 
conflict with BASIC programs. I decided to put the 
two together and generate a self-relocating MLM. 
That was desirable in early PET/CBM days, where 
some computers would come with 8K RAM, some 
with 16K, and others with 32K; you couldn't assume 
where the top of memory would be. 

In those days, almost every Commodore computer 
came with a small built- in MLM, and the first 
Supermon was an add-on. Later, as Commodore 
changed the style of the MLM packages they built 
into newer machines such as the 128, I went back 
and modified those earlier versions so that they 
would work the same across all platforms. 

Q: Did you ever expand the mini-assembler in 
SuperMon into a full-blown assembler development 
package? 

A: No. I hustled Brad Templeton into writing PAL, so 
that there would be an assembler available for those 
who needed it. There had been a few assemblers 
around before that - Commodore had one, and 
another was the MAE system - but I was sure that 
somebody like Brad could do better. 

Q: Even Superman had to put up with Kryptonite. 
Describe your worst experience as a software 
developer / technical writer. 

A: My first publication of SuperMon in Compute! 
magazine had the wrong end-of-address supplied 
(my fault). I got a LOT of mail and phone calls 
on that one. 

Q: I had heard a rumor pertaining to your software 
development habits that indicated you would 
approach a given project with full force. You would 
focus your undivided attention on it until it was 
complete. Is this rumor accurate? 

A: Possibly. If I have a project underway, it "follows 
me around" until 


it's complete; I fret over it and can't put it away until 
all the pieces are in place. 

Q: If so, did you ever change this methodology? 

A: Not to any great extent. A half-written program 
bugs me, and I won't rest until it's finished .1 might, 
however, decide that I'm taking the wrong track, and 
scrap a program completely in order to start over. 
This isn't a loss: the first attempt can show you 
what's really wanted. 

Q: Your articles made you seem a bit omniscient. 

You always had the inside info on the newest CBM 
computers and always seemed to be able to explain 
their complexities in a manner that would suggest 
that you had a lot of time to study them. I don't know 
a whole lot about your employment during the 
mid/late 80's. Were you affiliated with CBM? A 
beta-tester? 

A: I had many friends in Commodore Canada, but I 
never worked for the company, although I did 
contract work for them on occasion. 

The big problem was not getting information from 
Commodore; it was learning to ignore most of it. 
Commodore was bubbling over with ideas and plans 
that never came to fruition. There was no point in 
writing about projects that never happened (the 
Commodore music box? the cash register? the 
videotape/disk storage device?). I took the position: 
"Don't tell me about it until it's a real product!". 

Commodore Canada was an excellent source of 
information, and I relied on them to keep me from 
straying too far into technical speculation. 

Q: Did you use any high-level languages on CBM 
computers? 

A: BASIC, of course. COMAL, a BASIC derivative 
language from Denmark, was nicely constructed. 
Played around a little with C, but that language 
doesn't fit comfortably into an 8-bit environment. 

Q: What was your favorite computer that CBM 
produced? 

A: I don't know that I have a single favorite. The early 
PET/CBM machines were great "discovery" 
platforms, where we could investigate these 
wonderful new computers. The advent of the VIC-20 
and the Commodore 64 brought color and sound, 
which added to the charm of these home computers; 
but they paid a penalty in slow disk access and 
screen width limitations. Today, perhaps the 
Commodore 128 ranks as the best, or at least the 
computer with most general usability. But it wasn't 
produced in quantities as great as some of the earlier 
machines, and so the user community hasn't been 
quite as furious. 

Q: What kind of home computer do you currently 
use? 

A: Cl28 .. Amiga .. Pentium system. All three. 

Q: Who were your influences as related to writing? 

A: Nobody specific. Just tried to write it as I would 
say it. 

Q: Who were your influences as related to 
programming? 
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A: I've worked with a lot of sharp programmers over 
the years. Not one I can pick out especially. 

Q: If you could relive the CBM glory years, would you 
do anything differently? 

A: I don't think so. On another path, I could have 
gone for big bucks; but making money carries a 
responsibility to support and service, and 
that would have taken the fun out of it. 

Q: Is your current job computer-related? 

A: I'm currently more or less retired. 

Q: If you had not chosen a career in computing, what 
field of endeavor would you most likely have 
pursued? 

A: Before computers, I worked in electronics and 
telecommunications. 

Q: What are your current hobbies? 

A: Reading; travel; films; raising my daughter. (That's 
a hobby???) 

Q: What sort of technical literature do you currently 
read? 

A: Mostly reference material. Current magazines are 
heavy on the "what's for sale" stream; to my mind, 
that's not the fun part of computing. 


Q: Are you surprised that a sort of "CBM 
renaissance" has been taking place the last few 
years (...availability of C64 emulators on multiple 
platforms and such...the SuperCPU from CMD...). 

A: It's a shame that Commodore wasn't able 
to/interested in keeping the 8-bit line going. It's good 
to see that is happening. 

Surprised? A little. But enthusiasts and user groups 
have always had a stronger effect than 
manufacturers are willing to admit. 

Q: What is your opinion on the way consumer 
computing has evolved since the inception of the 
early PET machines? 

A: The average computer user today has a lot less 
fun than we still have with the early machines. The 
industry message today is "Buy it and use it, and 
then turn it off.. don't worry or think about how it all 
works". That's sure a lot less fun for tinkerers. 

Q: What words of wisdom would you care to impart 
on a new (or revitalized) generation of CBM hackers? 

A: Enjoy what you're doing! If it becomes drudgery, 
you're doing it wrong! 

Taken from http://www.radiks.net/~iimbo/art/c642.htm 
Commodore Free would like to thank Jim Lawless for 
permitting the reprinting of his interview with Jim 
Butterfield 
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